From cjplummer at openjdk.org  Thu May  1 03:04:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 May 2025 03:04:59 GMT
Subject: RFR: 8355773: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee
In-Reply-To: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
Message-ID: <CZMrlvx53rrfyVirLb4UcEh11SgqZLc792uUAMA9_jA=.bde173a8-2bf6-495c-a83a-52de2018065b@github.com>

On Thu, 1 May 2025 00:26:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
> 
> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
> 
> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
> 
> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001.java line 237:

> 235:                 }
> 236: 
> 237:                 thread2 = debuggee.threadByFieldNameOrThrow(debuggeeClass, "test_thread", threadName);

Note, mainThread is not reference later in the test so is no longer being looked up (and I deleted the field above). There are a couple more test below where the same is done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24979#discussion_r2069786848

From cjplummer at openjdk.org  Thu May  1 03:04:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 May 2025 03:04:59 GMT
Subject: RFR: 8355773: Some nsk/jdi tests can fetch ThreadReference from static
 field in the debuggee
Message-ID: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>

A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.

Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.

There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.

I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.

Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

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

Commit messages:
 - update copyrights
 - Fix exception message
 - Delete mainThread field. It is no used.
 - fix jcheck errors
 - Convert more tests to fetch the ThreadReference from a static in the debuggee

Changes: https://git.openjdk.org/jdk/pull/24979/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355773
  Stats: 1015 lines in 93 files changed: 186 ins; 614 del; 215 mod
  Patch: https://git.openjdk.org/jdk/pull/24979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24979/head:pull/24979

PR: https://git.openjdk.org/jdk/pull/24979

From kevinw at openjdk.org  Thu May  1 10:09:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 10:09:44 GMT
Subject: RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows [v2]
In-Reply-To: <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
Message-ID: <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>

On Wed, 30 Apr 2025 21:20:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I would simplify to 
>> 
>>  for (int i = 0; i < TEST_COUNT; i++) {
>>             double load = mbean.getProcessCpuLoad();
>>             if (load == -1.0 && Platform.isWindows()) {
>>                 // Some Windows 2019 systems can return -1 for the first few reads.
>>                 // Remember a -1 in case it never gets better.
>>                 // Some Windows systems can return -1 occasionally, at any time.
>>                 // Will fail if we never see good values.
>>                
>>             } else if (load < 0.0 || load > 1.0) {
>>                 throw new RuntimeException("getProcessCpuLoad() returns " + load
>>                           + " which is not in the [0.0,1.0] interval");
>>             } else { 
>>                // we got at least one load from 0.0 to 1.0, that's good to pass on Wiindows
>>                 good++;
>>           }
>>             try {
>>                 Thread.sleep(200);
>> 
>>             }
>>         }
>> 
>>     
>>         if (good == 0 && Platform.isWindows()) {
>>             // Never get any good results on Windows 2019
>>             throw throw new RuntimeException("getProcessCpuLoad() returns  always -1.0 on Windows in 10 attempts. ");
>>         }
>>     }
>> 
>> does it makes a sense?
>
> Thanks Leonid, yes we could do it like that.  There have to be a load of ways we could arrange this.  Yes, it could be a little simpler that what we have now, although it's not _that_ complicated now...

I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
I also like keeping the existing Exception wording, there isn't a real need to change it.
It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
On balance would you be OK if we leave as it stands?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070119265

From lmesnik at openjdk.org  Thu May  1 15:52:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 May 2025 15:52:48 GMT
Subject: RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows [v2]
In-Reply-To: <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
 <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
Message-ID: <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>

On Thu, 1 May 2025 10:07:04 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Thanks Leonid, yes we could do it like that.  There have to be a load of ways we could arrange this.  Yes, it could be a little simpler that what we have now, although it's not _that_ complicated now...
>
> I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
> I also like keeping the existing Exception wording, there isn't a real need to change it.
> It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
> On balance would you be OK if we leave as it stands?

sure, let left it as it is. 
Let return to this once 2019 is going to be EOL and remove all this stuff:
Looks good for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070435139

From kevinw at openjdk.org  Thu May  1 15:55:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 15:55:44 GMT
Subject: RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows [v2]
In-Reply-To: <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
 <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
 <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>
Message-ID: <lrPifNN_P8b4g_6VKhIMgy6yOA_zaycL86dVT3hz7Uo=.a3959245-3a52-4119-ab26-73a9d0bfe90d@github.com>

On Thu, 1 May 2025 15:49:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
>> I also like keeping the existing Exception wording, there isn't a real need to change it.
>> It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
>> On balance would you be OK if we leave as it stands?
>
> sure, let left it as it is. 
> Let return to this once 2019 is going to be EOL and remove all this stuff:
> Looks good for me.

Thanks Leonid!

Eventually there were a few failures on other Windows versions, so I removed the specific mention of Windows 2019, although it was most common.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070440202

From lmesnik at openjdk.org  Thu May  1 15:52:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 May 2025 15:52:46 GMT
Subject: RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows [v2]
In-Reply-To: <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
Message-ID: <dOQbLsuhj3ixdEi7GeofDBkboI1XlsP6voEk3MifiH4=.d5b27640-0b61-4a52-b629-01476d678443@github.com>

On Wed, 30 Apr 2025 18:42:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
>> 
>> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
>> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to check ex at end,  when failing

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24961#pullrequestreview-2810079167

From kevinw at openjdk.org  Thu May  1 16:08:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 16:08:50 GMT
Subject: Integrated: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows
In-Reply-To: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
Message-ID: <s_Uk3YYkvanCOOqD-ImjwLZjkaBXoaedWZYS8V3l1I8=.67ebdcb6-5292-4954-a8eb-28e2d417d089@github.com>

On Wed, 30 Apr 2025 11:13:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
> 
> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)

This pull request has now been integrated.

Changeset: 09cae5fd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09cae5fd8f228a8826e4de7aa43fe5365549c00c
Stats:     35 lines in 2 files changed: 5 ins; 24 del; 6 mod

8354407: Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on Windows

Reviewed-by: cjplummer, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/24961

From iveresov at openjdk.org  Thu May  1 16:58:39 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 1 May 2025 16:58:39 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v9]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <Z_XgwkUtFMxzDX43J2-Ts6crnTrjiYNpO2URtcTjisc=.b8b62075-2368-45fa-980e-9371f92ddf8c@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Port 8355915: [leyden] Crash in MDO clearing the unloaded array type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/b937681e..ee6bd11d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=07-08

  Stats: 17 lines in 4 files changed: 6 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Thu May  1 19:34:34 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 1 May 2025 19:34:34 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v10]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <4uRz9S2VvUHduPnG2Vnh3v-AbRtoB86mM1A9sJBLZ30=.840a3c9b-ada1-4ba4-b8d8-af4e94607556@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Fix semantics change from the previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/ee6bd11d..014b0ec5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/24886

From kevinw at openjdk.org  Thu May  1 16:08:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 16:08:50 GMT
Subject: RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on
 Windows [v2]
In-Reply-To: <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
Message-ID: <oRudO4wFOK863D4-G3xXTg_DKyyvrJWmqHshxeviggM=.cc668df4-34db-4700-a2b9-57109a096162@github.com>

On Wed, 30 Apr 2025 18:42:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
>> 
>> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
>> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to check ex at end,  when failing

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24961#issuecomment-2845146716

From amenkov at openjdk.org  Thu May  1 21:18:45 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 1 May 2025 21:18:45 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
Message-ID: <BfiJVwyg94jrLLVtxmmz-GxWgq-Cd50sMtb2zwnrNsk=.c4a4880e-4336-4c8f-a5d8-8a605b9dad1f@github.com>

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

Ping. Can I get review for this test update

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

PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2845798768

From sspitsyn at openjdk.org  Fri May  2 08:20:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 May 2025 08:20:06 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v5]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <ia29dTtCt5rfxB-WH-cu47e-WjzQlUQ3BF04fdToNLs=.ae68c812-f1f3-4d12-95b2-2385855db804@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

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

 - ?Merge?
 - review: added general comment about sync between suspend_thread and resume_thread
 - Merge
 - some cleanup
 - 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/df99ba15..f2c4a136

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=03-04

  Stats: 289018 lines in 2561 files changed: 84046 ins; 194950 del; 10022 mod
  Patch: https://git.openjdk.org/jdk/pull/24269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24269/head:pull/24269

PR: https://git.openjdk.org/jdk/pull/24269

From duke at openjdk.org  Fri May  2 10:00:07 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:07 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Refactor container runtime version code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/223a5d1b..3b18431d

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

  Stats: 246 lines in 3 files changed: 111 ins; 133 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Fri May  2 10:00:07 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:07 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <gEphzrXGgqwTdEt_h7V2O0QnbsxyKNFGP-lBeTS1c8w=.adcb76ed-5812-4b6e-a678-442b17ab7e71@github.com>
 <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
Message-ID: <_D4nqTI9xJUe43WrWHRaozFfHG5HQSv-jzFSNnrggmo=.fc3318d8-a776-48a3-b564-2d8e376bc299@github.com>

On Tue, 29 Apr 2025 20:18:17 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 74:
> 
>> 72:             return;
>> 73:         }
>> 74:         if (IS_DOCKER && TestDockerMemoryMetricsSubgroup.DockerVersion.VERSION_20_10_0.compareTo(getDockerVersion()) > 0) {
> 
> Should this change also cover Podman, in which the minimum version that supports `--cgroupns` is 3.0 ?

updated for podman
In podman cgroupns support was added in 1.5.0
https://github.com/containers/podman/releases?page=18

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071383984

From duke at openjdk.org  Fri May  2 10:00:08 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:08 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v2]
In-Reply-To: <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <gEphzrXGgqwTdEt_h7V2O0QnbsxyKNFGP-lBeTS1c8w=.adcb76ed-5812-4b6e-a678-442b17ab7e71@github.com>
 <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
Message-ID: <u6kJNmpRYPZSpoMT-87HNpk4orqhAqXeFySOu1SnY7Y=.e530c9cc-1ee2-4135-a8c5-281f36dcbb14@github.com>

On Tue, 29 Apr 2025 20:28:36 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update reference of DockerVersion
>
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 149:
> 
>> 147:     }
>> 148: 
>> 149:     private static class DockerVersion implements Comparable<TestDockerMemoryMetricsSubgroup.DockerVersion> {
> 
> The same code is added to multiple tests.

Created a util file for common code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071384406

From ayang at openjdk.org  Fri May  2 10:28:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 2 May 2025 10:28:55 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics
Message-ID: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>

This patch refines Parallel's sizing strategy to improve overall memory management and performance.

The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.

`NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.

GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.

## Performance evaluation

- SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
- Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
- Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.

PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.

Test: tier1-8

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

Commit messages:
 - pgc-size-policy

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338977
  Stats: 4365 lines in 29 files changed: 521 ins; 3446 del; 398 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From mli at openjdk.org  Fri May  2 10:48:50 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 2 May 2025 10:48:50 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v4]
In-Reply-To: <sNCddHgt1VcN3PisyrKHnZeDP3Mz8j9sgZCY0cIyG6c=.e0a5ccd3-c432-4557-9c7a-804896590854@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <sNCddHgt1VcN3PisyrKHnZeDP3Mz8j9sgZCY0cIyG6c=.e0a5ccd3-c432-4557-9c7a-804896590854@github.com>
Message-ID: <-bAHBy4AmqSglDpT2t94FrSQ7n1oFPkBDuxfcd2C0A8=.802dff01-b8da-439e-8b80-aa5dddc4031c@github.com>

On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

Looks good, thanks for fixing this and discussing!

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24229#pullrequestreview-2811707177

From coleenp at openjdk.org  Fri May  2 11:26:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 May 2025 11:26:50 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
Message-ID: <JLYAf54EBpaljt5ljWGjYTYMYrG4g9twBZW7doYe8gI=.bb15716f-f852-4344-b49b-1188279c828c@github.com>

On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix VerifyRawIndexesTest
>  - Fix reordering in layout and annotations
>  - Use qsort_r for different platforms

For the record, I'm reviewing and testing this PR also.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2846985137

From coleenp at openjdk.org  Fri May  2 11:26:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 May 2025 11:26:51 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <KMA52ZaSQs4Cxw-gCNBTq--yeETNyuIgJUtCX_2aUK0=.c7631b20-3b5b-42da-aaf0-c78749b21568@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <AR57NWg57E34aK0-iE7-OiDszVCj42SnBilcK6Hy0S8=.c5cab891-78bc-421c-bf5e-54fe6c8184b4@github.com>
 <KMA52ZaSQs4Cxw-gCNBTq--yeETNyuIgJUtCX_2aUK0=.c7631b20-3b5b-42da-aaf0-c78749b21568@github.com>
Message-ID: <gPs1JmZ7-KS0moFnr0c5bytRGdi0O30Yz2hV_20MtOY=.6101f4b9-427e-4e08-9ed0-637313480f18@github.com>

On Wed, 30 Apr 2025 20:15:36 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.hpp line 290:
>> 
>>> 288:   static int compare_symbols(const Symbol *s1, const Symbol *s2);
>>> 289: 
>>> 290:   static Array<u1>* create_FieldInfoStream(ConstantPool* constants, GrowableArray<FieldInfo>* fields, int java_fields, int injected_fields,
>> 
>> In the latest form the ConstantPool parameter is used only for assertion, though I think that it is rather important assertion.
>
> The ConstantPool parameter can be limited to debug builds (the ones with asserts) with the following patch:
> 
> 
> diff --git a/src/hotspot/share/classfile/classFileParser.cpp b/src/hotspot/share/classfile/classFileParser.cpp
> index 48646c0fb83..19471bbf7ee 100644
> --- a/src/hotspot/share/classfile/classFileParser.cpp
> +++ b/src/hotspot/share/classfile/classFileParser.cpp
> @@ -5813,7 +5813,7 @@ void ClassFileParser::post_process_parsed_stream(const ClassFileStream* const st
>  
>    int injected_fields_count = _temp_field_info->length() - _java_fields_count;
>    _fieldinfo_stream =
> -    FieldInfoStream::create_FieldInfoStream(_cp, _temp_field_info, _java_fields_count,
> +    FieldInfoStream::create_FieldInfoStream(DEBUG_ONLY(_cp COMMA) _temp_field_info, _java_fields_count,
>                                              injected_fields_count, loader_data(), CHECK);
>    _fields_status =
>      MetadataFactory::new_array<FieldStatus>(_loader_data, _temp_field_info->length(),
> diff --git a/src/hotspot/share/classfile/javaClasses.cpp b/src/hotspot/share/classfile/javaClasses.cpp
> index f3fdf28b96b..80ee179576c 100644
> --- a/src/hotspot/share/classfile/javaClasses.cpp
> +++ b/src/hotspot/share/classfile/javaClasses.cpp
> @@ -963,7 +963,7 @@ void java_lang_Class::fixup_mirror(Klass* k, TRAPS) {
>        }
>        Array<u1>* old_stream = ik->fieldinfo_stream();
>        assert(fields->length() == (java_fields + injected_fields), "Must be");
> -      Array<u1>* new_fis = FieldInfoStream::create_FieldInfoStream(ik->constants(), fields, java_fields, injected_fields, k->class_loader_data(), CHECK);
> +      Array<u1>* new_fis = FieldInfoStream::create_FieldInfoStream(DEBUG_ONLY(ik->constants() COMMA) fields, java_fields, injected_fields, k->class_loader_data(), CHECK);
>        ik->set_fieldinfo_stream(new_fis);
>        MetadataFactory::free_array<u1>(k->class_loader_data(), old_stream);
>      }
> diff --git a/src/hotspot/share/oops/fieldInfo.cpp b/src/hotspot/share/oops/fieldInfo.cpp
> index dd1fa11042d..eb90e6bdae8 100644
> --- a/src/hotspot/share/oops/fieldInfo.cpp
> +++ b/src/hotspot/share/oops/fieldInfo.cpp
> @@ -66,7 +66,7 @@ int FieldInfoStream::compare_symbols(const Symbol *s1, const Symbol *s2) {
>    }
>  }
>  
> -Array<u1>* FieldInfoStream::create_FieldInfoStream(ConstantPool* constants, GrowableArray<FieldInfo>* fields, int java_fields, int injected_fields,
> +Array<u1>* FieldInfoStream::create_FieldInfoStream(DEBUG_ONLY(ConstantPool* constants COMMA) GrowableArray<FieldInfo>* fields, int java_fields, int injected_f...

I don't think adding DEBUG_ONLY optimizes anything and kind of looks messy, I don't like this change unless the product compiler complains about an unused parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2071473593

From rehn at openjdk.org  Fri May  2 12:14:50 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 2 May 2025 12:14:50 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>
 <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
Message-ID: <Wo9l034gJIi6J6qCHg-BfWnbC0K-7Kom0fFkD3JMnNY=.8965162f-7071-49c8-a87f-90667e97bbf8@github.com>

On Thu, 27 Mar 2025 17:57:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into qemu-user-issues
>>  - more
>>  - more
>>  - native or very long
>
> I also feel annoying to see some tests fail interminently.
> 
> Not sure if I understand the goal of this pr, seems it might not be the best solution to simply disable these tests when running with qemu. My concerns are: qemu is still one of main methods to quickly verify the functionality changes, but when we just disable the failed tests, and maybe in the future disable more and more tests, then qemu is no longer able to play the role it was supposed to play.

Thanks @Hamlin-Li and @RealFYang.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2847064204

From sspitsyn at openjdk.org  Fri May  2 20:53:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 May 2025 20:53:30 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: patch from Patricio with alternate approach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/f2c4a136..168c1252

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=04-05

  Stats: 253 lines in 9 files changed: 84 ins; 104 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/24269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24269/head:pull/24269

PR: https://git.openjdk.org/jdk/pull/24269

From iveresov at openjdk.org  Sat May  3 01:13:41 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 3 May 2025 01:13:41 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v11]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <jclwOsb-ZI7zorMlTdWzOwenUFcJesHmgKw_LuVUd9Q=.e0cc58ba-c680-4246-babd-4df147e1e813@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with two additional commits since the last revision:

 - Fix additional issues
 - Make sure command line flags that affect MDO layout are consistent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/014b0ec5..9676039c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=09-10

  Stats: 54 lines in 3 files changed: 52 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Sat May  3 05:25:35 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 3 May 2025 05:25:35 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v12]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <GZ-aZBpn1yyyQeHDlYr8dcD-QB1pVxI5IwhjW-1C6tc=.600f79bd-310b-4f22-80f1-1280180b0284@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Fix compile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/9676039c..2441ad71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=10-11

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

PR: https://git.openjdk.org/jdk/pull/24886

From rvansa at openjdk.org  Mon May  5 06:30:49 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 06:30:49 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <lPiL1w0niscLkd_gobnhSOj3RIxCew4-iz6noaZoFM4=.2d277009-1dab-43d5-9dcc-d349aa784d6b@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <lPiL1w0niscLkd_gobnhSOj3RIxCew4-iz6noaZoFM4=.2d277009-1dab-43d5-9dcc-d349aa784d6b@github.com>
Message-ID: <-Xq9NUkXDnlFyKgh2juvL8zOFSxtc7AhEVBxfxo6w0Y=.2a611ac0-aca3-4ba6-beff-fb3daddba57a@github.com>

On Wed, 30 Apr 2025 20:12:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix VerifyRawIndexesTest
>>  - Fix reordering in layout and annotations
>>  - Use qsort_r for different platforms
>
> src/hotspot/share/oops/fieldInfo.hpp line 223:
> 
>> 221: };
>> 222: 
>> 223: #define JUMP_TABLE_STRIDE 16
> 
> How was the threshold of 16 determined?

I haven't done any benchmarks looking for the optimal value; this should balance the extra memory footprint vs. improved performance. Also I was hoping to not affect the bulk of Java code; rather optimize "big" classes that show degraded performance due to O(N) lookup.
How exactly could the optimization function look like if we're to weigh in both memory consumption and execution speed?

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 115:
> 
>> 113:     int numFields = numJavaFields + numInjectedFields;
>> 114:     // JumpTable is generated only for classes with > 16 (non-injected) fields
>> 115:     if (numJavaFields > 16) {
> 
> The test should use the `JUMP_TABLE_STRIDE` constant.

Sure, I can isolate this into static final var, though since this is Java code I can't really take the value from the macro.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2072899071
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2072899858

From rvansa at openjdk.org  Mon May  5 06:38:47 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 06:38:47 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
Message-ID: <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>

On Wed, 30 Apr 2025 20:19:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix VerifyRawIndexesTest
>>  - Fix reordering in layout and annotations
>>  - Use qsort_r for different platforms
>
> src/hotspot/share/oops/fieldInfo.cpp line 52:
> 
>> 50: 
>> 51: int FieldInfoStream::compare_symbols(const Symbol *s1, const Symbol *s2) {
>> 52:   // not lexicographical sort, since we need only total ordering
> 
> If only a total ordering is required, why defining a new method instead of reusing Symbol::fast_compare() ?

The problem is CDS; I have really started with `fast_compare()`, but after dehydration the pointers changed and the comparison did not work anymore. This is also a reason why I could not use the hashcode for the ordering.
If you'd prefer lexicographical sort (just a few extra lines) I could use that one...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2072906046

From rvansa at openjdk.org  Mon May  5 06:41:45 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 06:41:45 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
Message-ID: <OzurEUHPTIn5RDS8VqSnxujteoxCgkRy9XR5xh1qmrs=.0fb7605c-83ae-4a1b-b8c1-d34d817ac7eb@github.com>

On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix VerifyRawIndexesTest
>  - Fix reordering in layout and annotations
>  - Use qsort_r for different platforms

Thanks for test investigation! I noticed that some code could be dependent on the order of fields, though to my best knowledge the specification does not guarantee that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2850046799

From rvansa at openjdk.org  Mon May  5 06:51:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 06:51:31 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Move constant to static final var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/ef69ec06..7fb8d340

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/24847

From jsjolen at openjdk.org  Mon May  5 07:18:52 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 5 May 2025 07:18:52 GMT
Subject: RFR: 8355490: Make VM_RedefineClasses::merge_constant_pools only
 take reference arguments [v2]
In-Reply-To: <KW5vaJxRAYYHIefw6d8bhkoAvImPBi9J1kndhnVxcgU=.d39db5e2-22d3-4999-acff-4daf096e03bc@github.com>
References: <fdWr48IgHyBnCjHKw7NvyoyJadqzoRjdzO9z_UninO0=.797a9efc-c99b-4940-8006-8b11a73f93aa@github.com>
 <KW5vaJxRAYYHIefw6d8bhkoAvImPBi9J1kndhnVxcgU=.d39db5e2-22d3-4999-acff-4daf096e03bc@github.com>
Message-ID: <WFxrGGmqhJ_hlp19mn1i_Qem2iom5wuP2Z1OH13Xd_0=.e2f3005d-6e01-4c3c-9560-8fab7998e050@github.com>

On Fri, 25 Apr 2025 09:39:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> I've changed two pointer arguments to be references instead, as we bail if they are null and `assert(false)` on top of that. There are no other calls to this function than the one I fixed.
>> 
>> Testing: GHA Tier1
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Cheers!

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

PR Comment: https://git.openjdk.org/jdk/pull/24848#issuecomment-2850110102

From jsjolen at openjdk.org  Mon May  5 07:18:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 5 May 2025 07:18:53 GMT
Subject: Integrated: 8355490: Make VM_RedefineClasses::merge_constant_pools
 only take reference arguments
In-Reply-To: <fdWr48IgHyBnCjHKw7NvyoyJadqzoRjdzO9z_UninO0=.797a9efc-c99b-4940-8006-8b11a73f93aa@github.com>
References: <fdWr48IgHyBnCjHKw7NvyoyJadqzoRjdzO9z_UninO0=.797a9efc-c99b-4940-8006-8b11a73f93aa@github.com>
Message-ID: <Jt2qfZ-xXMZiXt40UeKI2gGCAmJ8_-m_TmevrWCpU7k=.55198e53-e515-458a-ad24-fe66c3194e87@github.com>

On Thu, 24 Apr 2025 12:09:36 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I've changed two pointer arguments to be references instead, as we bail if they are null and `assert(false)` on top of that. There are no other calls to this function than the one I fixed.
> 
> Testing: GHA Tier1

This pull request has now been integrated.

Changeset: 8511220f
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8511220f9dd1428f9793ead43c20ed197881ab36
Stats:     40 lines in 2 files changed: 0 ins; 8 del; 32 mod

8355490: Make VM_RedefineClasses::merge_constant_pools only take reference arguments

Reviewed-by: amenkov, sspitsyn, coleenp

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

PR: https://git.openjdk.org/jdk/pull/24848

From sspitsyn at openjdk.org  Mon May  5 10:29:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 May 2025 10:29:47 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
Message-ID: <5lfUq5HfAC5gCZClRSo-diFj7LOjn6vm-PZbmC-Y2KY=.e0ab99e8-4fe0-4b6c-8f8a-8cf1fe69500e@github.com>

On Fri, 2 May 2025 20:53:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: patch from Patricio with alternate approach

I've pushed update with Patricio's suggestion. Mach5 testing is green.
Also, I've decided to keep my fixes in the `jvmtiThreadState.?pp`. It feels it does not worth to separate those.

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2850564367

From rehn at openjdk.org  Mon May  5 11:46:55 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 5 May 2025 11:46:55 GMT
Subject: Integrated: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <csvX_w1hA9B3MIjrHyD57vRuUuQpv2RUz0zw9gs3xNM=.3a9cfd13-641e-4679-82da-f473093e5bca@github.com>

On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch explicit or implicit (sysroot).
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

This pull request has now been integrated.

Changeset: 02647976
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/026479767c011227b63e7fdb8a38f61977782249
Stats:     71 lines in 64 files changed: 71 ins; 0 del; 0 mod

8352730: RISC-V: Disable tests in qemu-user

Reviewed-by: fyang, mli

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

PR: https://git.openjdk.org/jdk/pull/24229

From rvansa at openjdk.org  Mon May  5 12:54:52 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 12:54:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <B7H2qO5cNSarP3LaCYEtXjG0r446ghb4nHfJnJEgR2Q=.1bea1883-aec8-4c60-a310-b9d3a29b17b0@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

For the record, in the ideal case I would like to backport this into JDK 21 as well. Do you think that the change in iteration order would be problematic for that?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2850897668

From hgreule at openjdk.org  Mon May  5 13:46:47 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 5 May 2025 13:46:47 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <B7H2qO5cNSarP3LaCYEtXjG0r446ghb4nHfJnJEgR2Q=.1bea1883-aec8-4c60-a310-b9d3a29b17b0@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <B7H2qO5cNSarP3LaCYEtXjG0r446ghb4nHfJnJEgR2Q=.1bea1883-aec8-4c60-a310-b9d3a29b17b0@github.com>
Message-ID: <vdzwwSfitEuYADgzFH-lgOazIvOnUZwxuYLr0TuAzJU=.c7b3c05a-34e0-442a-b43b-6170329849d6@github.com>

On Mon, 5 May 2025 12:51:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> For the record, in the ideal case I would like to backport this into JDK 21 as well. Do you think that the change in iteration order would be problematic for that?

I think that also affects iteration order of Java methods like `Class#getDeclaredFields()` etc.? While the order is unspecified there, I'm pretty certain that it would break existing code. But even worse, [JVM TI specifies that `GetClassFields` returns fields in the order they occur in the class file](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#GetClassFields). I assume this is currently broken?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851062633

From rvansa at openjdk.org  Mon May  5 13:59:48 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 13:59:48 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <vdzwwSfitEuYADgzFH-lgOazIvOnUZwxuYLr0TuAzJU=.c7b3c05a-34e0-442a-b43b-6170329849d6@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <B7H2qO5cNSarP3LaCYEtXjG0r446ghb4nHfJnJEgR2Q=.1bea1883-aec8-4c60-a310-b9d3a29b17b0@github.com>
 <vdzwwSfitEuYADgzFH-lgOazIvOnUZwxuYLr0TuAzJU=.c7b3c05a-34e0-442a-b43b-6170329849d6@github.com>
Message-ID: <Zp2XBuqerdsopI2UAwOO2KWnuSNZGcywVRAKMBCGwyI=.ecfe0622-8c13-4bfe-95c6-c26e2b46bd8a@github.com>

On Mon, 5 May 2025 13:44:32 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> For the record, in the ideal case I would like to backport this into JDK 21 as well. Do you think that the change in iteration order would be problematic for that?
>
>> For the record, in the ideal case I would like to backport this into JDK 21 as well. Do you think that the change in iteration order would be problematic for that?
> 
> I think that also affects iteration order of Java methods like `Class#getDeclaredFields()` etc.? While the order is unspecified there, I'm pretty certain that it would break existing code. But even worse, [JVM TI specifies that `GetClassFields` returns fields in the order they occur in the class file](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#GetClassFields). I assume this is currently broken?

@SirYwell Oh, that's correct. I haven't noticed that requirement; I guess that this means that the PR needs to be updated. 

How does the order of iteration cooperate with `@Contended`, though? In `FieldLayoutBuilder::regular_field_sorting` we separate static and contended fields; doesn't that break the requirement?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851099200

From hgreule at openjdk.org  Mon May  5 14:17:47 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 5 May 2025 14:17:47 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <Zp2XBuqerdsopI2UAwOO2KWnuSNZGcywVRAKMBCGwyI=.ecfe0622-8c13-4bfe-95c6-c26e2b46bd8a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <B7H2qO5cNSarP3LaCYEtXjG0r446ghb4nHfJnJEgR2Q=.1bea1883-aec8-4c60-a310-b9d3a29b17b0@github.com>
 <vdzwwSfitEuYADgzFH-lgOazIvOnUZwxuYLr0TuAzJU=.c7b3c05a-34e0-442a-b43b-6170329849d6@github.com>
 <Zp2XBuqerdsopI2UAwOO2KWnuSNZGcywVRAKMBCGwyI=.ecfe0622-8c13-4bfe-95c6-c26e2b46bd8a@github.com>
Message-ID: <ssfdLMTUI9WKuqBUHrMoYc04NOvy01-qGWZpupyaZJc=.175cb47d-d317-470c-a1f7-0af7e033b6bc@github.com>

On Mon, 5 May 2025 13:57:10 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> How does the order of iteration cooperate with `@Contended`, though? In `FieldLayoutBuilder::regular_field_sorting` we separate static and contended fields; doesn't that break the requirement?

Hm, I'm not familiar enough with the code there. There seem to be some rather basic tests here https://github.com/openjdk/jdk/tree/1501a5e41e59162a374cf5b8cfc37faced48a6ed/test/hotspot/jtreg/serviceability/jvmti/GetClassFields and here https://github.com/openjdk/jdk/tree/1501a5e41e59162a374cf5b8cfc37faced48a6ed/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields (I think https://github.com/openjdk/jdk/blob/1501a5e41e59162a374cf5b8cfc37faced48a6ed/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp#L129 actually tests the order), but nothing with `@Contended` involved. Maybe it is worth to expand the test coverage first?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851151806

From coleenp at openjdk.org  Mon May  5 14:56:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 5 May 2025 14:56:49 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <D2wpXX11A4epLjBuv0o7moPDvDY9N-gU1a9dJ1KUDa0=.f23e7243-7992-439c-91f5-f936dbf53b06@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

For Methods we sort them alphabetically but have a field in InstanceKlass called method_ordering to preserve the original order for JVMTI.  This would have to have the same thing.  I'm wondering if instead this patch could create a cache of the FieldInfoStream in InstanceKlass for certain heuristics.  It would add a pointer to InstanceKlass that will be null when there's nothing to cache, but could be used to improve performance of this edge case.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851271657

From coleenp at openjdk.org  Mon May  5 15:02:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 5 May 2025 15:02:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <szJF_YgQLulgWpyGDcJ_6e-7LJ__Vj2OMe_2sGvTepQ=.5f2339e3-4018-4a9c-b6cc-bcf4aecc948d@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

Also should probably add your test to test/micro/org/openjdk/bench as a JMH

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851287976

From pchilanomate at openjdk.org  Mon May  5 15:10:52 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 5 May 2025 15:10:52 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
Message-ID: <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>

On Fri, 2 May 2025 20:53:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: patch from Patricio with alternate approach

Thanks for adopting the suggestion Serguei!

src/hotspot/share/prims/jvmtiEnv.cpp line 1124:

> 1122:       oop carrier_thread = java_lang_VirtualThread::carrier_thread(thread_oop);
> 1123:       java_thread = carrier_thread == nullptr ? nullptr : java_lang_Thread::thread(carrier_thread);
> 1124:     }      

Nit: extra spaces at the end. There are a couple of other instances of this in this file shown by jcheck.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1798:

> 1796:       return JVMTI_ERROR_THREAD_SUSPENDED;
> 1797:     }
> 1798:     if (!java_thread->java_suspend(single_suspend)) {

We could use `is_virtual && single_suspend` (same in resume) and change `_handshakee->is_vthread_mounted()` to be an assert in `HandshakeState::set_suspended()`.

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

PR Review: https://git.openjdk.org/jdk/pull/24269#pullrequestreview-2815125142
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2073621313
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2073634025

From rvansa at openjdk.org  Mon May  5 18:39:49 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 May 2025 18:39:49 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <szJF_YgQLulgWpyGDcJ_6e-7LJ__Vj2OMe_2sGvTepQ=.5f2339e3-4018-4a9c-b6cc-bcf4aecc948d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <szJF_YgQLulgWpyGDcJ_6e-7LJ__Vj2OMe_2sGvTepQ=.5f2339e3-4018-4a9c-b6cc-bcf4aecc948d@github.com>
Message-ID: <GRNMB4WXbu0OY09VE-PITDP9rLin4TsPAekeLN7fCQw=.2523ac42-fe86-48e4-9050-49ba51dd43a3@github.com>

On Mon, 5 May 2025 15:00:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move constant to static final var
>
> Also should probably add your test to test/micro/org/openjdk/bench as a JMH

@coleenp I wouldn't mind keeping the order in InstanceKlass (or elsewhere), but it would increase memory usage - and through this go against the idea from https://bugs.openjdk.org/browse/JDK-8292818 that tries to reduce the memory footprint. Would that be acceptable?
If methods are already sorted alphabetically, it would make sense for fields, too.

> I'm wondering if instead this patch could create a cache of the FieldInfoStream in InstanceKlass for certain heuristics.

If we'd have something like a complete n-ary tree or hashtable, it would most likely take several bytes per field. I am not sure how much memory can I sacrifice... Even if we can have the structure only for 'big' classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2851974225

From sspitsyn at openjdk.org  Mon May  5 23:21:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 May 2025 23:21:20 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
 <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
Message-ID: <HXQ1ySJKe4wjQMjXX6vz25GeK-7N6hEqXEaUvu6WWlk=.150445c1-23df-4c8b-a3e6-83a0d22feb08@github.com>

On Mon, 5 May 2025 14:58:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: patch from Patricio with alternate approach
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1124:
> 
>> 1122:       oop carrier_thread = java_lang_VirtualThread::carrier_thread(thread_oop);
>> 1123:       java_thread = carrier_thread == nullptr ? nullptr : java_lang_Thread::thread(carrier_thread);
>> 1124:     }      
> 
> Nit: extra spaces at the end. There are a couple of other instances of this in this file shown by jcheck.

Fixed now, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2074359226

From sspitsyn at openjdk.org  Mon May  5 23:55:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 May 2025 23:55:21 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
 <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
Message-ID: <7kiM8LZK2bDJRk34o6fQHGbf1NZwdHsZTz77dHCt8jo=.9dee85fd-2557-4a6a-baf0-e8df4047c9c2@github.com>

On Mon, 5 May 2025 15:06:37 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: patch from Patricio with alternate approach
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1798:
> 
>> 1796:       return JVMTI_ERROR_THREAD_SUSPENDED;
>> 1797:     }
>> 1798:     if (!java_thread->java_suspend(single_suspend)) {
> 
> We could use `is_virtual && single_suspend` (same in resume) and change `_handshakee->is_vthread_mounted()` to be an assert in `HandshakeState::set_suspended()`.

Thank you for suggestion. Let me check if I understand you right.
We can rename the parameter `update_vthread_list` to `register_vthread_suspend_or_resume` and pass `is_virtual && single_suspend` instead of `single_suspend` to `java_suspend()` and `java_resume()`.
We also want to change the `HandshakeState::set_suspended()` as below:

void HandshakeState::set_suspended(bool is_suspend, bool register_vthread_suspend_or_resume) {
#if INCLUDE_JVMTI
  if (register_vthread_suspend_or_resume) {
    assert(_handshakee->is_vthread_mounted(), "sanity check");
    if (is_suspend) {
      JvmtiVTSuspender::register_vthread_suspend(_handshakee->vthread());
    } else {
      JvmtiVTSuspender::register_vthread_resume(_handshakee->vthread());
    }
  }
#endif
  Atomic::store(&_suspended, is_suspend);
}


Is this correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2074407231

From sspitsyn at openjdk.org  Tue May  6 00:02:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 00:02:49 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v7]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <pPv4uW-Dpmh1cZj952uTTb6iy-u_CQjvi7oqU0qJFII=.35d9ba4a-e9e8-402a-8c5c-ca900da7b44c@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix trailing spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/168c1252..b2c413a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/24269

From sspitsyn at openjdk.org  Tue May  6 00:37:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 00:37:17 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
Message-ID: <KaXD7hKJUkzWlKXRq8i9I4VR3s6tnuhKIE-QS9CPbPE=.07fb41a6-fb97-4ecb-99c0-c23e2a874147@github.com>

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

The fix looks good to me. Nice unification with simplifications.

test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54:

> 52: 
> 53:         pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail"));
> 54:         System.out.println("Address is " + Long.toHexString(addr));

Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24672#pullrequestreview-2816484606
PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2074470851

From sspitsyn at openjdk.org  Tue May  6 04:38:14 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 04:38:14 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <7kiM8LZK2bDJRk34o6fQHGbf1NZwdHsZTz77dHCt8jo=.9dee85fd-2557-4a6a-baf0-e8df4047c9c2@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
 <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
 <7kiM8LZK2bDJRk34o6fQHGbf1NZwdHsZTz77dHCt8jo=.9dee85fd-2557-4a6a-baf0-e8df4047c9c2@github.com>
Message-ID: <Tvh00UILYzY_ELZYYEC7n7AjRXD4pf1Pv-zqvIpbj1M=.29e52592-ea69-4d07-97f2-61aae4df1eb3@github.com>

On Mon, 5 May 2025 23:53:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1798:
>> 
>>> 1796:       return JVMTI_ERROR_THREAD_SUSPENDED;
>>> 1797:     }
>>> 1798:     if (!java_thread->java_suspend(single_suspend)) {
>> 
>> We could use `is_virtual && single_suspend` (same in resume) and change `_handshakee->is_vthread_mounted()` to be an assert in `HandshakeState::set_suspended()`.
>
> Thank you for suggestion. Let me check if I understand you right.
> We can rename the parameter `update_vthread_list` to `register_vthread_SR` and pass `is_virtual && single_suspend` instead of `single_suspend` to `java_suspend()` and `java_resume()`.
> We also want to change the `HandshakeState::set_suspended()` as below:
> 
> void HandshakeState::set_suspended(bool is_suspend, bool register_vthread_SR) {
> #if INCLUDE_JVMTI
>   if (register_vthread_SR) {
>     assert(_handshakee->is_vthread_mounted(), "sanity check");
>     if (is_suspend) {
>       JvmtiVTSuspender::register_vthread_suspend(_handshakee->vthread());
>     } else {
>       JvmtiVTSuspender::register_vthread_resume(_handshakee->vthread());
>     }
>   }
> #endif
>   Atomic::store(&_suspended, is_suspend);
> }
> 
> 
> Is this correct? If so, then I think it is a good suggestion.

It feels like all the `HandshakeState` SR code can be moved from `handshake.?pp` to` jvmtiEnvBase.?pp` as it seems to be a little bit unnatural for `HandshakeState`. The `JvmtiThreadState_lock` or some other lock can be used for waiting in the suspended state. Then some attempts to simplify this code could be made. But it does not look as very important at this point in time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2074721380

From iveresov at openjdk.org  Tue May  6 06:31:43 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 6 May 2025 06:31:43 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <ijYhqOit_mx3zn7aBy2NpG1j6qyoYG5IXxDDaiyXl-c=.7bd82d1b-b8c5-4047-b892-8e8579c03948@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge branch 'master' into pp2
 - Fix compile
 - Fix additional issues
 - Make sure command line flags that affect MDO layout are consistent
 - Fix semantics change from the previous commit
 - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type
 - Fix flag behavior
 - Fix log tags
 - Remove the proxy class counter
 - Address review comments part 2
 - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=12
  Stats: 3231 lines in 60 files changed: 3011 ins; 103 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From sspitsyn at openjdk.org  Tue May  6 08:36:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 08:36:24 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode
Message-ID: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>

This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
 - The `interp_only_mode` in `JavaThread` is represented with a counter which is increment and decremented. This is confusing because this value should only take values `0` and `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
 - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
 
 Testing:
  - TBD: Mach5 tiers 1-6

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

Commit messages:
 - 8356251: Need minor cleanup for interp_only_mode

Changes: https://git.openjdk.org/jdk/pull/25060/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25060&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356251
  Stats: 11 lines in 3 files changed: 1 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25060.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25060/head:pull/25060

PR: https://git.openjdk.org/jdk/pull/25060

From sspitsyn at openjdk.org  Tue May  6 08:42:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 08:42:29 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v8]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <KDIysugGttYPdO4T6tuy2Ey8ZV_XWeI_B-eGjs4GwEI=.0d327c5a-3860-4089-87ba-0edbfb5298c8@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: some minor refactoring for parameter update_vthread_list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/b2c413a7..0a29d0b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=06-07

  Stats: 27 lines in 5 files changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/24269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24269/head:pull/24269

PR: https://git.openjdk.org/jdk/pull/24269

From sspitsyn at openjdk.org  Tue May  6 08:42:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 08:42:29 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <Tvh00UILYzY_ELZYYEC7n7AjRXD4pf1Pv-zqvIpbj1M=.29e52592-ea69-4d07-97f2-61aae4df1eb3@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
 <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
 <7kiM8LZK2bDJRk34o6fQHGbf1NZwdHsZTz77dHCt8jo=.9dee85fd-2557-4a6a-baf0-e8df4047c9c2@github.com>
 <Tvh00UILYzY_ELZYYEC7n7AjRXD4pf1Pv-zqvIpbj1M=.29e52592-ea69-4d07-97f2-61aae4df1eb3@github.com>
Message-ID: <5cS67w1ai1kTFNpr9XWnFewGFhsLSSBxhOMFdrAUT1Y=.78ff4f27-e34a-4485-8f27-9b599c88f764@github.com>

On Tue, 6 May 2025 04:35:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thank you for suggestion. Let me check if I understand you right.
>> We can rename the parameter `update_vthread_list` to `register_vthread_SR` and pass `is_virtual && single_suspend` instead of `single_suspend` to `java_suspend()` and `java_resume()`.
>> We also want to change the `HandshakeState::set_suspended()` as below:
>> 
>> void HandshakeState::set_suspended(bool is_suspend, bool register_vthread_SR) {
>> #if INCLUDE_JVMTI
>>   if (register_vthread_SR) {
>>     assert(_handshakee->is_vthread_mounted(), "sanity check");
>>     if (is_suspend) {
>>       JvmtiVTSuspender::register_vthread_suspend(_handshakee->vthread());
>>     } else {
>>       JvmtiVTSuspender::register_vthread_resume(_handshakee->vthread());
>>     }
>>   }
>> #endif
>>   Atomic::store(&_suspended, is_suspend);
>> }
>> 
>> 
>> Is this correct? If so, then I think it is a good suggestion.
>
> It feels like all the `HandshakeState` SR code can be moved from `handshake.?pp` to` jvmtiEnvBase.?pp` as it seems to be a little bit unnatural for `HandshakeState`. The `JvmtiThreadState_lock` or some other lock can be used for waiting in the suspended state. Then some attempts to simplify this code could be made. But it does not look as very important at this point in time.

I've pushed the fix suggested above. Please, let me know if it looks right or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2074995937

From kevinw at openjdk.org  Tue May  6 11:13:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 6 May 2025 11:13:06 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows)
Message-ID: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>

OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
"maximum clock function return value of 2147483.647 seconds, or about 24.8 days"

The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.

The example code also notes that _ftime is deprecated, so _ftime_s is used here.

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

Commit messages:
 - 8351359: OperatingSystemMXBean stops reporting cpuLoad and processCpuLoad after 24.8 days

Changes: https://git.openjdk.org/jdk/pull/25062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351359
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25062/head:pull/25062

PR: https://git.openjdk.org/jdk/pull/25062

From pchilanomate at openjdk.org  Tue May  6 16:29:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 May 2025 16:29:17 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v8]
In-Reply-To: <KDIysugGttYPdO4T6tuy2Ey8ZV_XWeI_B-eGjs4GwEI=.0d327c5a-3860-4089-87ba-0edbfb5298c8@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <KDIysugGttYPdO4T6tuy2Ey8ZV_XWeI_B-eGjs4GwEI=.0d327c5a-3860-4089-87ba-0edbfb5298c8@github.com>
Message-ID: <1yOSNB0lT2rNZkbYEnLvH7LwM_DeWSE78M90txGAzck=.6c8a700f-aef1-4d0c-9cee-f8d02ffc1f7c@github.com>

On Tue, 6 May 2025 08:42:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: some minor refactoring for parameter update_vthread_list

I only see some extra trailing spaces in file `src/hotspot/share/prims/jvmtiEnvBase.cpp` but otherwise changes look good!

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2855207210

From pchilanomate at openjdk.org  Tue May  6 16:29:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 May 2025 16:29:18 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v6]
In-Reply-To: <5cS67w1ai1kTFNpr9XWnFewGFhsLSSBxhOMFdrAUT1Y=.78ff4f27-e34a-4485-8f27-9b599c88f764@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <ZhvtvjKInKNbaUPsh02T-ZH5sdoSJb379vG-2KjV4Bk=.50529b04-a617-4cd1-94b8-495c1c29b680@github.com>
 <a-gG_Q7Aadw7Cm1BeZCJDYq7VA4TVBZ1RCuLp36OoYI=.ca0464cc-984b-44f0-85e8-d5e24b960e8b@github.com>
 <7kiM8LZK2bDJRk34o6fQHGbf1NZwdHsZTz77dHCt8jo=.9dee85fd-2557-4a6a-baf0-e8df4047c9c2@github.com>
 <Tvh00UILYzY_ELZYYEC7n7AjRXD4pf1Pv-zqvIpbj1M=.29e52592-ea69-4d07-97f2-61aae4df1eb3@github.com>
 <5cS67w1ai1kTFNpr9XWnFewGFhsLSSBxhOMFdrAUT1Y=.78ff4f27-e34a-4485-8f27-9b599c88f764@github.com>
Message-ID: <Xu5I8ac30OD4WMGgqKwur-ljmWf-Dku_moj6tOcXRks=.55d86848-1890-4b78-86f9-61e524cf36aa@github.com>

On Tue, 6 May 2025 08:36:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It feels like all the `HandshakeState` SR code can be moved from `handshake.?pp` to` jvmtiEnvBase.?pp` as it seems to be a little bit unnatural for `HandshakeState`. The `JvmtiThreadState_lock` or some other lock can be used for waiting in the suspended state. Then some attempts to simplify this code could be made. But it does not look as very important at this point in time.
>
> I've pushed the fix suggested above. Please, let me know if it looks right or not.

Great. Yes, that was the suggestion. I didn't think about renaming the parameter but I like the new name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2075844072

From sspitsyn at openjdk.org  Tue May  6 17:04:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 17:04:58 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v9]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  reivew: fix more trailing spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/0a29d0b5..4023a19c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/24269

From sspitsyn at openjdk.org  Tue May  6 17:04:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 17:04:58 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v8]
In-Reply-To: <1yOSNB0lT2rNZkbYEnLvH7LwM_DeWSE78M90txGAzck=.6c8a700f-aef1-4d0c-9cee-f8d02ffc1f7c@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <KDIysugGttYPdO4T6tuy2Ey8ZV_XWeI_B-eGjs4GwEI=.0d327c5a-3860-4089-87ba-0edbfb5298c8@github.com>
 <1yOSNB0lT2rNZkbYEnLvH7LwM_DeWSE78M90txGAzck=.6c8a700f-aef1-4d0c-9cee-f8d02ffc1f7c@github.com>
Message-ID: <4nriveMHOhyJpwbJh8iSmGwNJSxsEynlcTDZE9_bsxw=.6dead211-af73-4db3-bbcd-0d41bbf54e70@github.com>

On Tue, 6 May 2025 16:26:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I only see some extra trailing spaces in file src/hotspot/share/prims/jvmtiEnvBase.cpp but otherwise changes look good!

Thanks, I've fixed trailing spaces now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2855303446

From pchilanomate at openjdk.org  Tue May  6 17:40:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 May 2025 17:40:17 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v9]
In-Reply-To: <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
Message-ID: <J3xUawBFGl5Ojja7v-FBKsaJQRKDYsQVgp9IQWbtogY=.2a8d7799-2542-4f4e-b477-d7a437217112@github.com>

On Tue, 6 May 2025 17:04:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reivew: fix more trailing spaces

Thanks Serguei!

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24269#pullrequestreview-2819126419

From sspitsyn at openjdk.org  Tue May  6 18:12:14 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 18:12:14 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v9]
In-Reply-To: <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
Message-ID: <7wrFLK505ojLkD9Qaeo52Zf_XTa28riurIR2bKFnYwM=.7ca1c72c-1bd7-4850-bad2-eb40993e0ea3@github.com>

On Tue, 6 May 2025 17:04:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reivew: fix more trailing spaces

Thank you a lot for review and suggestions, Patricio!

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2855488652

From lmesnik at openjdk.org  Tue May  6 18:32:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 6 May 2025 18:32:14 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode
In-Reply-To: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
Message-ID: <8-jSItxSwhqU969dSkiClU-YDK-nUULgh1bcnS9HMdg=.6e6912e4-45fb-48ea-b62f-8d0286088283@github.com>

On Tue, 6 May 2025 08:29:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is increment and decremented. This is confusing because this value should only take values `0` and `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>  
>  Testing:
>   - TBD: Mach5 tiers 1-6

Changes requested by lmesnik (Reviewer).

src/hotspot/share/runtime/javaThread.hpp line 1177:

> 1175:   bool is_interp_only_mode()                { return (_interp_only_mode != 0); }
> 1176:   int get_interp_only_mode()                { return _interp_only_mode; }
> 1177:   int set_interp_only_mode(int val)         { return _interp_only_mode = val; }

Ther get_interp_only_mode() /set_interp_only_mode(int val)  also might be eliminated and replaced by set/clear instead.

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

PR Review: https://git.openjdk.org/jdk/pull/25060#pullrequestreview-2819254877
PR Review Comment: https://git.openjdk.org/jdk/pull/25060#discussion_r2076039987

From cjplummer at openjdk.org  Tue May  6 18:51:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 May 2025 18:51:18 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13]
In-Reply-To: <ijYhqOit_mx3zn7aBy2NpG1j6qyoYG5IXxDDaiyXl-c=.7bd82d1b-b8c5-4047-b892-8e8579c03948@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ijYhqOit_mx3zn7aBy2NpG1j6qyoYG5IXxDDaiyXl-c=.7bd82d1b-b8c5-4047-b892-8e8579c03948@github.com>
Message-ID: <c37AQzAz6fFrOqQZYjhWHOPx_mKmHm4Ka7ejhGXLk1k=.d0a4acea-6584-4ba0-9c7e-cb4b45636b63@github.com>

On Tue, 6 May 2025 06:31:43 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - Merge branch 'master' into pp2
>  - Fix compile
>  - Fix additional issues
>  - Make sure command line flags that affect MDO layout are consistent
>  - Fix semantics change from the previous commit
>  - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type
>  - Fix flag behavior
>  - Fix log tags
>  - Remove the proxy class counter
>  - Address review comments part 2
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 129:

> 127:     metadataTypeArray[5] = db.lookupType("InstanceStackChunkKlass");
> 128:     metadataTypeArray[6] = db.lookupType("Method");
> 129:     metadataTypeArray[9] = db.lookupType("MethodData");

It looks like MethodData inheriting from Metadata is not a new change, but has always been the case. I'm surprised this didn't cause any test failures before your changes. Did you end up with test failures after your changes?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 154:

> 152:         if (!VM.getVM().isCore()) {
> 153:             virtualConstructor.addMapping("CompilerThread", CompilerThread.class);
> 154:             virtualConstructor.addMapping("TrainingReplayThread", TrainingReplayThread.class);

The new SA TrainingReplayThread class is not needed since it only overrides isHiddenFromExternalView() to return true. You can instead use HiddenJavaThread.class here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076064357
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076058595

From cjplummer at openjdk.org  Tue May  6 19:02:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 May 2025 19:02:19 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
Message-ID: <HrzhkRF6_DcNTPudFxzJ_Pd_Eu0PTE-j-3Ft41mApQU=.ed63d548-28f5-4e27-bb7c-747ef4fc1baf@github.com>

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

So this issue is only with tests that attach back to the test process?

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

PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2855609698

From amenkov at openjdk.org  Tue May  6 19:29:17 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 May 2025 19:29:17 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <HrzhkRF6_DcNTPudFxzJ_Pd_Eu0PTE-j-3Ft41mApQU=.ed63d548-28f5-4e27-bb7c-747ef4fc1baf@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
 <HrzhkRF6_DcNTPudFxzJ_Pd_Eu0PTE-j-3Ft41mApQU=.ed63d548-28f5-4e27-bb7c-747ef4fc1baf@github.com>
Message-ID: <rrv_IiS5wJjfNH0hewMKCSmPAD4lBYU-igcYBRCKhdU=.a5c94594-d929-47eb-b35e-4f102223f89e@github.com>

On Tue, 6 May 2025 18:59:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> So this issue is only with tests that attach back to the test process?

Yes. There is no issues when tests create dedicated process as target VM.

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

PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2855690778

From lmesnik at openjdk.org  Tue May  6 19:33:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 6 May 2025 19:33:14 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v9]
In-Reply-To: <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
Message-ID: <RgW1g7wSNT2VwvCcmMtoyu4fS1zi_uRQXfzXMlsYHyU=.26b68711-91d7-4109-b0db-b05af5812a12@github.com>

On Tue, 6 May 2025 17:04:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reivew: fix more trailing spaces

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24269#pullrequestreview-2819396994

From amenkov at openjdk.org  Tue May  6 19:36:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 May 2025 19:36:13 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <KaXD7hKJUkzWlKXRq8i9I4VR3s6tnuhKIE-QS9CPbPE=.07fb41a6-fb97-4ecb-99c0-c23e2a874147@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
 <KaXD7hKJUkzWlKXRq8i9I4VR3s6tnuhKIE-QS9CPbPE=.07fb41a6-fb97-4ecb-99c0-c23e2a874147@github.com>
Message-ID: <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com>

On Tue, 6 May 2025 00:32:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The change is a preparation step to enable attach streaming output by default.
>> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
>> Details in the first comment.
>> Testing: tier1..7 with enabled attach streaming output
>
> test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54:
> 
>> 52: 
>> 53:         pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail"));
>> 54:         System.out.println("Address is " + Long.toHexString(addr));
> 
> Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here?

The test uses created ProcessBuilder many times, so the test would require much more changes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2076129633

From sspitsyn at openjdk.org  Tue May  6 21:46:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 21:46:21 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v9]
In-Reply-To: <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
 <bgQlSOyJ3Ej9brtDF6uNYgd6SCB5YAI3HdSGZFuxyYE=.59ba187f-a9e4-4641-bc2a-4dfdb615990c@github.com>
Message-ID: <rQ9v0c5GiumGzADn6raIF_3MOYK2VJZKPmpxkiLXP6Y=.c7073024-5022-4ab4-b35f-8df0bbaa9733@github.com>

On Tue, 6 May 2025 17:04:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
>> 
>> Testing: Ran mach5 tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reivew: fix more trailing spaces

Thank you for review, Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2856131702

From iveresov at openjdk.org  Tue May  6 21:50:34 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 6 May 2025 21:50:34 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v14]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/7d22a42a..11e3c398

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=12-13

  Stats: 36 lines in 2 files changed: 0 ins; 35 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Tue May  6 21:50:36 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 6 May 2025 21:50:36 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13]
In-Reply-To: <c37AQzAz6fFrOqQZYjhWHOPx_mKmHm4Ka7ejhGXLk1k=.d0a4acea-6584-4ba0-9c7e-cb4b45636b63@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ijYhqOit_mx3zn7aBy2NpG1j6qyoYG5IXxDDaiyXl-c=.7bd82d1b-b8c5-4047-b892-8e8579c03948@github.com>
 <c37AQzAz6fFrOqQZYjhWHOPx_mKmHm4Ka7ejhGXLk1k=.d0a4acea-6584-4ba0-9c7e-cb4b45636b63@github.com>
Message-ID: <GImVV6Q9aeDYZjPwWceObRy83GFEcBdAFMiCnGxt51Q=.6c5b6afc-ea3f-43fd-bf33-708289034070@github.com>

On Tue, 6 May 2025 18:48:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
>> 
>>  - Merge branch 'master' into pp2
>>  - Fix compile
>>  - Fix additional issues
>>  - Make sure command line flags that affect MDO layout are consistent
>>  - Fix semantics change from the previous commit
>>  - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type
>>  - Fix flag behavior
>>  - Fix log tags
>>  - Remove the proxy class counter
>>  - Address review comments part 2
>>  - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 129:
> 
>> 127:     metadataTypeArray[5] = db.lookupType("InstanceStackChunkKlass");
>> 128:     metadataTypeArray[6] = db.lookupType("Method");
>> 129:     metadataTypeArray[9] = db.lookupType("MethodData");
> 
> It looks like MethodData inheriting from Metadata is not a new change, but has always been the case. I'm surprised this didn't cause any test failures before your changes. Did you end up with test failures after your changes?

Honestly I don't remember, I think @iklam did these changes.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 154:
> 
>> 152:         if (!VM.getVM().isCore()) {
>> 153:             virtualConstructor.addMapping("CompilerThread", CompilerThread.class);
>> 154:             virtualConstructor.addMapping("TrainingReplayThread", TrainingReplayThread.class);
> 
> The new SA TrainingReplayThread class is not needed since it only overrides isHiddenFromExternalView() to return true. You can instead use HiddenJavaThread.class here.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076373507
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076369998

From sspitsyn at openjdk.org  Tue May  6 22:12:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 May 2025 22:12:24 GMT
Subject: Integrated: 8316682:
 serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <yi9BDJATrdfzsWoCmcq2Y0_89fS4WYjqvlKXfwockbc=.670a2628-96f8-46c3-919c-46854430f91c@github.com>

On Thu, 27 Mar 2025 01:10:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

This pull request has now been integrated.

Changeset: 9a23f721
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a23f721c7bcbfdb2fcf5b2bd145d6967e000dc4
Stats:     204 lines in 13 files changed: 82 ins; 57 del; 65 mod

8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out

Reviewed-by: lmesnik, pchilanomate

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

PR: https://git.openjdk.org/jdk/pull/24269

From cjplummer at openjdk.org  Tue May  6 22:47:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 May 2025 22:47:13 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
Message-ID: <5OdwszO_QsJhBfsJSCkxMjnpcHRd0HNCFbWjeiqc37w=.b6c15111-d499-41d5-b92b-01248e9cafda@github.com>

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24672#pullrequestreview-2819881603

From amenkov at openjdk.org  Tue May  6 23:36:17 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 May 2025 23:36:17 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2
In-Reply-To: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
Message-ID: <MXvBzQzsDzmuvXNJ4HTH5qccGc-9GM1zdjrLDZpUfDM=.a7ecee7d-29b6-441b-9693-d31d28e3a6f6@github.com>

On Thu, 1 May 2025 00:26:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
> 
> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
> 
> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
> 
> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

Looks good in general, good to see all this stuff dropped.
One file has only copyright line change.

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001a.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2025, Oracle and/or its affiliates. All rights reserved.

There are no changes in the file

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

PR Review: https://git.openjdk.org/jdk/pull/24979#pullrequestreview-2819960690
PR Review Comment: https://git.openjdk.org/jdk/pull/24979#discussion_r2076528196

From sspitsyn at openjdk.org  Wed May  7 00:28:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 00:28:18 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode
In-Reply-To: <8-jSItxSwhqU969dSkiClU-YDK-nUULgh1bcnS9HMdg=.6e6912e4-45fb-48ea-b62f-8d0286088283@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <8-jSItxSwhqU969dSkiClU-YDK-nUULgh1bcnS9HMdg=.6e6912e4-45fb-48ea-b62f-8d0286088283@github.com>
Message-ID: <J6gbLmOpOx9OZ-a77OcAB7UjGtXxRdWQH7WHEEi4zME=.a0126ea0-fad4-4b21-8add-950e9dd0019e@github.com>

On Tue, 6 May 2025 18:29:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> src/hotspot/share/runtime/javaThread.hpp line 1177:
> 
>> 1175:   bool is_interp_only_mode()                { return (_interp_only_mode != 0); }
>> 1176:   int get_interp_only_mode()                { return _interp_only_mode; }
>> 1177:   int set_interp_only_mode(int val)         { return _interp_only_mode = val; }
> 
> Ther get_interp_only_mode() /set_interp_only_mode(int val)  also might be eliminated and replaced by set/clear instead.

Good suggestion, thanks. Updated, it is being tested now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25060#discussion_r2076576748

From sspitsyn at openjdk.org  Wed May  7 00:36:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 00:36:34 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
Message-ID: <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>

> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>  
>  Testing:
>   - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove get_interp_only_mode(), set_interp_only_mode() and clear_interp_only_mode()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25060/files
  - new: https://git.openjdk.org/jdk/pull/25060/files/d1ac6b5f..c4d167c4

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

  Stats: 12 lines in 4 files changed: 1 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25060.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25060/head:pull/25060

PR: https://git.openjdk.org/jdk/pull/25060

From amenkov at openjdk.org  Wed May  7 00:41:18 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 00:41:18 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <eEgCmGXb70ETbxYs9kPVDcB8DXLLXxxq2u2YywU49uI=.861055ef-d84b-4ba1-98ea-ce13bd24db29@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

I'm not sure use current system time here is a good idea. system time may be updated (manually or automatically) and this will break the logic (if you change system time 1 hour back, there will be no updates for the next hour..)
May be use `GetTickCount`? it's low-res (10ms IIRC), but it's ok for the case.
It overflows in 50 days, but there is no problem is you use DWORD arithmetic. Or newer `GetTickCount64` (available from Vista) may be used instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2856684373

From cjplummer at openjdk.org  Wed May  7 02:24:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 May 2025 02:24:00 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2 [v2]
In-Reply-To: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
Message-ID: <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>

> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
> 
> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
> 
> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
> 
> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  undo copyright change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24979/files
  - new: https://git.openjdk.org/jdk/pull/24979/files/c43ff38c..3f7c4a03

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

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

PR: https://git.openjdk.org/jdk/pull/24979

From cjplummer at openjdk.org  Wed May  7 02:32:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 May 2025 02:32:18 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
Message-ID: <lSdXMS_XmUFpNYiCOvD5XEYjfh4T1xWQLiSXbJYee1k=.13bcf23d-9d05-42e9-ae20-00334654b14a@github.com>

On Wed, 7 May 2025 00:36:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove get_interp_only_mode(), set_interp_only_mode() and clear_interp_only_mode()

> The interp_only_mode in a JavaThread is checked by the interpreter chunks which expect it to be an integer. This cleanup has no intention to make it a boolean.

I think this should be documented.

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2856839161

From kevinw at openjdk.org  Wed May  7 11:25:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 May 2025 11:25:32 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Use GetTickCount64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25062/files
  - new: https://git.openjdk.org/jdk/pull/25062/files/3dd8362f..c7861219

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

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

PR: https://git.openjdk.org/jdk/pull/25062

From kevinw at openjdk.org  Wed May  7 11:25:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 May 2025 11:25:32 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <ckG6ttuudtK0ta4M-Zzjzg4kcoF1IITCtznl5xHv7dE=.e1b99183-538a-41d8-830a-3a4d2427d0de@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

Thanks Alex -
Yes, good point, and luckily it isn't that bad.  GetTickCount64 does look like a good choice, I'm updating this.  _ftime_s() works fine in practice but GetTickCount64 seems like a better choice.

Testing existing behaviour using clock(), using _ftime_s(), and using GetTickCount64(): setting the clock back breaks one sample, we return -1, and keep returning that for one sampling "window", then it's fixed.  That's a reasonable disruption when the system time is changed, and is how it's always been.

With ftime_s() I suppose it's the negative time difference being treated as an unsigned uint64_t, it's a very big number, so the behaviour is the same as other methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2858199438

From cjplummer at openjdk.org  Wed May  7 17:03:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 May 2025 17:03:22 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v14]
In-Reply-To: <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
Message-ID: <hie_-VQ7_Y1scmNSnXQpTZT_YP0NJ2vDvv6j79xIjlQ=.92df79e0-886d-457c-ad06-46944895f61e@github.com>

On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2822536705

From sspitsyn at openjdk.org  Wed May  7 17:47:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 17:47:18 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
 <KaXD7hKJUkzWlKXRq8i9I4VR3s6tnuhKIE-QS9CPbPE=.07fb41a6-fb97-4ecb-99c0-c23e2a874147@github.com>
 <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com>
Message-ID: <Nmq5ELlc22E_NwvubS1GmGbH6PX5igRVky8wLqivklE=.209c2087-f7cd-4a60-8194-4a6d92a97567@github.com>

On Tue, 6 May 2025 19:33:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54:
>> 
>>> 52: 
>>> 53:         pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail"));
>>> 54:         System.out.println("Address is " + Long.toHexString(addr));
>> 
>> Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here?
>
> The test uses created ProcessBuilder many times, so the test would require much more changes

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2078164486

From amenkov at openjdk.org  Wed May  7 18:10:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 18:10:13 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2 [v2]
In-Reply-To: <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
 <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
Message-ID: <O05U3E8Ycr1Gs3NBh-VglpBKw-W9TTLXUvzylkHV6sU=.089f92c1-4227-4521-b4cc-99c2ac5080cf@github.com>

On Wed, 7 May 2025 02:24:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
>> 
>> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
>> 
>> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
>> 
>> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
>> 
>> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo copyright change

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24979#pullrequestreview-2822736355

From amenkov at openjdk.org  Wed May  7 18:21:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 18:21:37 GMT
Subject: Integrated: 8354461: Update tests to disable streaming output for
 attach tools
In-Reply-To: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
References: <EzQX2noe2cAI7X1s8KjhHm473ItRJMUyGqiEn6BMhls=.bb722472-70b6-45e8-bf8c-512bab1b3815@github.com>
Message-ID: <dNqLYsCQtzQUUkoDpEBem_glZk1DixsDbes5Ux582so=.1ab6042b-aefd-4c54-aac4-56461fd9380d@github.com>

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

This pull request has now been integrated.

Changeset: cb021580
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb02158090fa97bf4d11d09c23ce3058a5f83fc8
Stats:     159 lines in 19 files changed: 44 ins; 56 del; 59 mod

8354461: Update tests to disable streaming output for attach tools

Reviewed-by: sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/24672

From amenkov at openjdk.org  Wed May  7 18:30:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 18:30:56 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <nmybMCSqbQ7Qjq5IOzCDRBKkKPUwpUmPaN_dbGHFs1E=.e81229ca-07f1-44cc-9477-e5c57d01e0be@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> The example code also notes that _ftime is deprecated, so _ftime_s is used here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25062#pullrequestreview-2822755498

From coleenp at openjdk.org  Wed May  7 19:21:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 May 2025 19:21:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <GRNMB4WXbu0OY09VE-PITDP9rLin4TsPAekeLN7fCQw=.2523ac42-fe86-48e4-9050-49ba51dd43a3@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <szJF_YgQLulgWpyGDcJ_6e-7LJ__Vj2OMe_2sGvTepQ=.5f2339e3-4018-4a9c-b6cc-bcf4aecc948d@github.com>
 <GRNMB4WXbu0OY09VE-PITDP9rLin4TsPAekeLN7fCQw=.2523ac42-fe86-48e4-9050-49ba51dd43a3@github.com>
Message-ID: <TnhMzJu7axls4dxRQAAgkRGV7MCmBVQJ0cPM6_e_83k=.fc83eca8-88c7-446b-a849-d71b40aeaa82@github.com>

On Mon, 5 May 2025 18:36:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> If methods are already sorted alphabetically, it would make sense for fields, too.

Yeah, you'd want to use the same mechanism.  So each InstanceKlass will have an additional 64 bit pointer, and this mapping array if JVMTI is on.  For methods, there's a capability that you can test `can_maintain_original_method_order` but I don't see the same capability for fields.  I assume it's because fields have never previously been reordered (?) from declaration order.

Maybe the compression is still a win in footprint size with this extra pointer and mapping array.  It would be a savings with your class with your huge number of fields.  The other reason to compress the field stream was to avoid null bytes for fields where the attributes didn't apply (init, generic signature, etc).

Compressing the fields into unsigned5 and decoding them into streams was quite a complicated change but manageable because the interface to decode them is all one has write the FieldStream iterator. This is hard to review.

I'm wondering how much of a problem this is in real code, other than the case with 21k fields and if there's a way to programmatically work around this case, like decompress the fields into a hashtable or something (?)  It would be interesting to see some histograms of some corpus Java code (maybe put this info in the associated bug).

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2859962231

From coleenp at openjdk.org  Wed May  7 19:29:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 May 2025 19:29:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <3V_WQOwuNCXdGsueCdoHb70KNE8HdkspVDPDh4rRkAQ=.13bbd49b-26ff-4e87-ab30-80650e311a20@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

Fred tells me that we already store the original field index so maybe above is moot.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2859987801

From sspitsyn at openjdk.org  Wed May  7 22:13:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 22:13:52 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2 [v2]
In-Reply-To: <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
 <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
Message-ID: <tlGZsHXskHnF443FKcgf45lpeMDWTREOcRSU4-BJiMQ=.df2fe5ab-0d5a-4b25-b1d7-7cf5f37b9bd2@github.com>

On Wed, 7 May 2025 02:24:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
>> 
>> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
>> 
>> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
>> 
>> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
>> 
>> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo copyright change

This is also a nice unification, simplification and cleanup. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24979#pullrequestreview-2823325504

From sspitsyn at openjdk.org  Wed May  7 22:24:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 22:24:51 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <z_AlzI-m_lDAxanpgO0E8_d8fSId3UWapHN5ZCFA8l8=.26dc81d2-750b-48db-a94f-8c7b4554c744@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> Update: GetTickCount64() is a better alternative.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25062#pullrequestreview-2823339785

From sgehwolf at openjdk.org  Thu May  8 08:40:00 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 8 May 2025 08:40:00 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v17]
In-Reply-To: <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
Message-ID: <y53dT7rff0wHm0GwfQ-SvCUUD0H9OAwUZYv0gQ9xdYQ=.8fdaa0f3-3a61-48b0-9901-1d17c051fa8d@github.com>

On Tue, 1 Apr 2025 14:59:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - JDK-8350103
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6

Keep open, bot.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2862232316

From stefank at openjdk.org  Thu May  8 10:06:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 10:06:47 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with outside
 TLAB allocations
Message-ID: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>

While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java

The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.

The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.

The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.

The idea is to better account how much we have allocated in three different buckets:
* Outside of TLAB allocations
* Accounted TLAB allocations
* The last bit of TLAB allocations that hasn't been accounted yet

And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.

There are a few things to think about when reading this code:
* The thread can allocate and retire multiple TLABs before we cross the sample threshold.
* The sampling can take multiple samples in a single TLAB
* Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.

There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:

1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
2) Moved thread allocation accounting and sampling code out of the TLAB
3) Moved retiring of TLABs out of make_parseable (needed to support (2))

Some of that could be extracted into a separate PR if that's deemed worthwhile.

Tested with the HeapMonitor tests various TLAB sizes.

If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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

Commit messages:
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Changes: https://git.openjdk.org/jdk/pull/25114/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356372
  Stats: 224 lines in 14 files changed: 136 ins; 42 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

PR: https://git.openjdk.org/jdk/pull/25114

From kevinw at openjdk.org  Thu May  8 13:20:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 13:20:57 GMT
Subject: RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <FXdPsgBz8d6mE-whWjTo0N75W_-f9fs0x6KrDpjgRNk=.768e7183-50e3-4e21-9fd6-4e21b88eeb2e@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> Update: GetTickCount64() is a better alternative.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Thanks Alex, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2863032652

From kevinw at openjdk.org  Thu May  8 13:20:58 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 13:20:58 GMT
Subject: Integrated: 8351359: OperatingSystemMXBean: values from getCpuLoad and
 getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <90Y3fwOBgHupYnvL-f7UhsmcvUmLgEpi1Lyf3sjwGIs=.2fde9f7c-9ba7-4f79-8308-225808c30c11@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> Update: GetTickCount64() is a better alternative.

This pull request has now been integrated.

Changeset: 900b3ff7
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/900b3ff7ee933520efe2438fb7c841a4e6a93d17
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8351359: OperatingSystemMXBean: values from getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25062

From mbaesken at openjdk.org  Thu May  8 13:54:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 May 2025 13:54:58 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
Message-ID: <0MvaSKWRsIMKLk243wtixaCcKnNukwftJGg_yzHDTvo=.298e599e-de85-42c5-b2bd-cad7ad630fc7@github.com>

On Wed, 9 Apr 2025 12:33:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
>> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
>> 
>> On Linux x86_64 for example the lib shrinks from
>> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
>> 
>> On Linux ppc64le for example the lib shrinks from
>> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .
>
> I'd like to move to a world where we basically have just two optimization levels, "size" and "speed", and libraries do not in general have the level specified, so it falls back on a default, which could then be set by configure. For individual libraries we might need to override the default value, if we know that certain compilers make a mess of certain optimization levels, or if some libraries are especially performance sensitive. (Making hotspot `-Os` would certainly never make any sense, for example.)

@magicus should we close this one and follow up with another JBS issue, making opt-size the default for JDK libs ? I think you proposed something like this ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2863156276

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

PR: https://git.openjdk.org/jdk/pull/25122

From lmesnik at openjdk.org  Thu May  8 15:05:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 15:05:53 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
Message-ID: <mbAaqipUIs8qekc1qw8KVfHW13U6scNfw_cXnkml3BU=.28648981-95c6-4b81-9151-7df990fa0f5f@github.com>

On Wed, 7 May 2025 00:36:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove get_interp_only_mode(), set_interp_only_mode() and clear_interp_only_mode()

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25060#pullrequestreview-2825459109

From lmesnik at openjdk.org  Thu May  8 15:07:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 15:07:04 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2 [v2]
In-Reply-To: <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
 <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
Message-ID: <qBMtYqimpdK6O_CHMW07FZAzUZTLllEi6UafA24yE_Q=.f4c25bd9-098b-4a1e-8bea-122c97b53733@github.com>

On Wed, 7 May 2025 02:24:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
>> 
>> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
>> 
>> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
>> 
>> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
>> 
>> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo copyright change

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24979#pullrequestreview-2825463308

From pchilanomate at openjdk.org  Thu May  8 15:54:25 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 15:54:25 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
Message-ID: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>

Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).

I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).

I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/25119/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346255
  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119

PR: https://git.openjdk.org/jdk/pull/25119

From reto.merz at abacus.ch  Thu May  8 16:01:52 2025
From: reto.merz at abacus.ch (Reto Merz)
Date: Thu, 8 May 2025 16:01:52 +0000
Subject: Finding application errors that unnecessarily consume memory -
 Proposal for SoftXmx
Message-ID: <GVAP278MB0437BCFA20F77A575E1B7192FA8BA@GVAP278MB0437.CHEP278.PROD.OUTLOOK.COM>

Hi all,

I wasn't exactly sure which mailing list I should post this to. It's about a kind of "monitoring":

We are a provider of ERP software written in Java.
Users can log in to our software and perform various "application-level" tasks there.
These include, for example, entering master data (addresses, project infos, etc.),
financial tasks like paying or creating invoices, as well as accounting processes such as payroll.

A logged-in user has a session. Our software starts multiple JVMs.
When a user logs in, a decision is made on which JVM their session will run.
Now, there are some things that are held centrally in caches and therefore do not need to be loaded per session but per JVM.
Other things, however, are specifically assigned to a session, and only that session needs this data at that moment.
To find application programming errors that unnecessarily consume a lot of memory,
we start a relatively large number of JVMs, give them little memory (Xmx), and set -XX:+HeapDumpOnOutOfMemoryError.
If a session needs a lot of memory briefly, and the JVM throws an OutOfMemoryError, then we have a dump and can examine it.

Example:
We start 4 JVMs with Xmx=1GB. If there is exactly 1 session and it briefly requests 1.5GB of memory due to an application error
then there is an OutOfMemoryError, and we have a HeapDump.
If we were to run only 1 JVM with Xmx=4GB, then in this case, there would be no OutOfMemoryError, and everything would continue to run.
Which is actually not bad for the user. However, we find fewer memory problems in our application code this way.
Because normally, a session needs about 16MB. Of course, there are certain processes that require many times that amount of memory briefly.
For example, when a session does a payroll run, it might need 50MB of memory for a short time.

I wanted to ask how others might be doing this. What we are already doing is collecting and monitoring metrics.

An idea that we have, and which would be very practical for us, is if there were a kind of "soft memory threshold" for the JVM/GC.
The JVM/GC would then try not to exceed this. If it has to, then the same mechanisms would be useful as for "OnOutOfMemoryError".
So, no OutOfMemoryError would be thrown, but the JVM could allocate the memory, but a one-time event would be triggered, for example "OnOutOfSoftMemory".
Analogous to -XX:+HeapDumpOnOutOfMemoryError, there could then be an option -XX:+HeapDumpOnOutOfSoftMemory where a HeapDump is generated.
Or a -XX:OnOutOfSoftMemory=string to execute a command or script.

Concrete example:
The JVM could be set with for example a "SoftXmx=1GB", a "Xmx=2GB", and a -XX:+HeapDumpOnOutOfSoftMemory.
If we think back to the case from above where 1 session briefly requests 1.5GB of memory,
then a HeapDump would be created, but everything would continue to run normally.

Now I wanted to ask if such a feature would be conceivable and what your general thoughts are on it.

Thank you very much,

Regards,
Reto Merz


From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From cjplummer at openjdk.org  Thu May  8 17:51:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 8 May 2025 17:51:59 GMT
Subject: RFR: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2 [v2]
In-Reply-To: <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
 <rsib_dz4HsC7sQaqcRRBmyWwcmHV737otZ3ueGoMdis=.72c02937-5ec1-49fe-90e3-669cbf4bcc0a@github.com>
Message-ID: <_N4GAyOYG4ksZbOonoi0idxYIIevreuDXjn_sgh2giQ=.f58c3abd-5bd4-449b-b5bf-fd16cb93e8e4@github.com>

On Wed, 7 May 2025 02:24:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
>> 
>> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
>> 
>> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
>> 
>> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
>> 
>> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo copyright change

Thank you for the reviews Alex, Serguei, and Leonid.

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

PR Comment: https://git.openjdk.org/jdk/pull/24979#issuecomment-2863820341

From cjplummer at openjdk.org  Thu May  8 17:51:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 8 May 2025 17:51:59 GMT
Subject: Integrated: 8356023: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 2
In-Reply-To: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
References: <lskFNBodLIkUs9g31El9_m1uREVWR-5Vd7lgxqc0NpY=.7ac4de3e-c7f3-4fe8-bcf1-92ea3c9ea121@github.com>
Message-ID: <jINW18Ip_mgu8uTNhRJFon5Jwaks3UoF1CkKPxE7ytQ=.ea6adb08-b7fa-4a7f-9700-2103d04c1a5c@github.com>

On Thu, 1 May 2025 00:26:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773). Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773) focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.
> 
> Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the `listIterator` variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.
> 
> There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.
> 
> I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

This pull request has now been integrated.

Changeset: 92730945
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/927309453822183bbfa9af278043fe0dca17031c
Stats:     1014 lines in 92 files changed: 186 ins; 614 del; 214 mod

8356023: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 2

Reviewed-by: amenkov, sspitsyn, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/24979

From liach at openjdk.org  Thu May  8 17:59:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 17:59:28 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
Message-ID: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>

For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

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

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - 8356548: Avoid using ASM to parse latest class files in tests

Changes: https://git.openjdk.org/jdk/pull/25124/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356548
  Stats: 291 lines in 8 files changed: 99 ins; 136 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From sspitsyn at openjdk.org  Thu May  8 18:18:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 May 2025 18:18:52 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <lSdXMS_XmUFpNYiCOvD5XEYjfh4T1xWQLiSXbJYee1k=.13bcf23d-9d05-42e9-ae20-00334654b14a@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
 <lSdXMS_XmUFpNYiCOvD5XEYjfh4T1xWQLiSXbJYee1k=.13bcf23d-9d05-42e9-ae20-00334654b14a@github.com>
Message-ID: <Wo1f8BmKGt_LihNHZJIHS4vwuP0tT0-h3kyIbKFHrN0=.3eb020ed-a888-485b-b8e5-78612e491ad7@github.com>

On Wed, 7 May 2025 02:29:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The interp_only_mode in a JavaThread is checked by the interpreter chunks which expect it to be an integer. This cleanup has no intention to make it a boolean.

> I think this should be documented.

Do you mean we need a comment somewhere to explain this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2863884022

From sspitsyn at openjdk.org  Thu May  8 18:18:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 May 2025 18:18:53 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
Message-ID: <YR5YcxjldtZN9tGuZXkwKGjmk7QkvYGdgCQKhpmmzOA=.0d227814-f521-4613-ba62-24625da11d15@github.com>

On Wed, 7 May 2025 00:36:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove get_interp_only_mode(), set_interp_only_mode() and clear_interp_only_mode()

Thank you for review, Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2863885439

From cjplummer at openjdk.org  Thu May  8 18:26:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 8 May 2025 18:26:51 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <Wo1f8BmKGt_LihNHZJIHS4vwuP0tT0-h3kyIbKFHrN0=.3eb020ed-a888-485b-b8e5-78612e491ad7@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
 <lSdXMS_XmUFpNYiCOvD5XEYjfh4T1xWQLiSXbJYee1k=.13bcf23d-9d05-42e9-ae20-00334654b14a@github.com>
 <Wo1f8BmKGt_LihNHZJIHS4vwuP0tT0-h3kyIbKFHrN0=.3eb020ed-a888-485b-b8e5-78612e491ad7@github.com>
Message-ID: <B3YiX6wC9Pg_ntkYl-oGLCjQTHEDK_NJTCkugE2p3n8=.b27575c8-68b4-4459-a861-1de46cf180fb@github.com>

On Thu, 8 May 2025 18:15:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > > The interp_only_mode in a JavaThread is checked by the interpreter chunks which expect it to be an integer. This cleanup has no intention to make it a boolean.
> 
> > I think this should be documented.
> 
> Do you mean we need a comment somewhere to explain this?

Yes. Maybe with the declaration.

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2863901625

From coleenp at openjdk.org  Thu May  8 18:35:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 May 2025 18:35:54 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <i6YAalTbd_gHH40T5qqgP0C13S82TbS260AMhHLUPk4=.ee5e37ee-3c2d-4cbb-a388-75a7ff4b9afd@github.com>

On Thu, 8 May 2025 14:57:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java line 76:

> 74:             throw new Error("TESTBUG: Can't get code source" + ex, ex);
> 75:         }
> 76:         try (FileInputStream fis = new FileInputStream(filePath.toFile())) {

Don't you have to delete lines 149-155 also?

test/hotspot/jtreg/runtime/MirrorFrame/Test8003720.java line 30:

> 28:  * @library /testlibrary/asm
> 29:  * @modules java.base/jdk.internal.misc
> 30:  * @compile -XDignore.symbol.file -source 21 -target 21 Victim.java

Why is this necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2080231780
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2080233032

From liach at openjdk.org  Thu May  8 18:35:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:35:55 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
In-Reply-To: <i6YAalTbd_gHH40T5qqgP0C13S82TbS260AMhHLUPk4=.ee5e37ee-3c2d-4cbb-a388-75a7ff4b9afd@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i6YAalTbd_gHH40T5qqgP0C13S82TbS260AMhHLUPk4=.ee5e37ee-3c2d-4cbb-a388-75a7ff4b9afd@github.com>
Message-ID: <r2f8sZOB6spg-6Zw5vBeVDpnt6IZzdW0OD584vVkrUk=.9a224ae5-5a3c-49ff-bacf-c423e96262bd@github.com>

On Thu, 8 May 2025 18:23:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java line 76:
> 
>> 74:             throw new Error("TESTBUG: Can't get code source" + ex, ex);
>> 75:         }
>> 76:         try (FileInputStream fis = new FileInputStream(filePath.toFile())) {
> 
> Don't you have to delete lines 149-155 also?

This path is used to dump the destination bytes. I tried to use `test.classes` to dump the output bytes but to no avail - seems libraries have some custom mechanisms, that I can neither find the location of their classes, nor can I easily pass javac flags for libraries via jtreg.

> test/hotspot/jtreg/runtime/MirrorFrame/Test8003720.java line 30:
> 
>> 28:  * @library /testlibrary/asm
>> 29:  * @modules java.base/jdk.internal.misc
>> 30:  * @compile -XDignore.symbol.file -source 21 -target 21 Victim.java
> 
> Why is this necessary?

The Asmator uses objectweb ASM to transform Victim, which means ASM needs to parse the javac output Victim.class. If this class wishes to be backported in the future, this flag ensures the output class file is of a constant version that ASM on older versions can consistently parse.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2080260173
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2080256577

From alanb at openjdk.org  Thu May  8 19:19:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:19:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>

On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:

> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
> 98:         awaitBlocked(thread1, reached1);
> 99:         awaitBlocked(thread2, reached2);

This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 

An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080327776

From pchilanomate at openjdk.org  Thu May  8 19:52:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 19:52:17 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Rename awaitBlocked to awaitTrueAndBlocked

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25119/files
  - new: https://git.openjdk.org/jdk/pull/25119/files/7c067865..c36728d8

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

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

PR: https://git.openjdk.org/jdk/pull/25119

From pchilanomate at openjdk.org  Thu May  8 19:52:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 19:52:17 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
Message-ID: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>

On Thu, 8 May 2025 19:17:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename awaitBlocked to awaitTrueAndBlocked
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:
> 
>> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
>> 98:         awaitBlocked(thread1, reached1);
>> 99:         awaitBlocked(thread2, reached2);
> 
> This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 
> 
> An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.

Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead.

Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080371142

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From kevinw at openjdk.org  Thu May  8 20:10:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 20:10:53 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <LqGdRNr_zUBsyuA5yy44ly_sSynJ0j9M6umfjfnCeME=.8857875d-ceb0-4e00-b284-d997065246aa@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Hi, looks good!

(The flag is easier than trying to look at the name of the thing they are blocked on.)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826251302

From ron.pressler at oracle.com  Thu May  8 21:04:33 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 8 May 2025 21:04:33 +0000
Subject: Finding application errors that unnecessarily consume memory -
 Proposal for SoftXmx
In-Reply-To: <GVAP278MB0437BCFA20F77A575E1B7192FA8BA@GVAP278MB0437.CHEP278.PROD.OUTLOOK.COM>
References: <GVAP278MB0437BCFA20F77A575E1B7192FA8BA@GVAP278MB0437.CHEP278.PROD.OUTLOOK.COM>
Message-ID: <E86E2942-B797-475F-982D-BE5475362934@oracle.com>

Hi.

ZGC already has -XX:SoftMaxHeapSize. I think this draft JEP could be of interest to you: https://openjdk.org/jeps/8329758

? Ron

> On 8 May 2025, at 17:01, Reto Merz <reto.merz at abacus.ch> wrote:
> 
> Hi all,
> 
> I wasn't exactly sure which mailing list I should post this to. It's about a kind of "monitoring":
> 
> We are a provider of ERP software written in Java.
> Users can log in to our software and perform various "application-level" tasks there.
> These include, for example, entering master data (addresses, project infos, etc.),
> financial tasks like paying or creating invoices, as well as accounting processes such as payroll.
> 
> A logged-in user has a session. Our software starts multiple JVMs.
> When a user logs in, a decision is made on which JVM their session will run.
> Now, there are some things that are held centrally in caches and therefore do not need to be loaded per session but per JVM.
> Other things, however, are specifically assigned to a session, and only that session needs this data at that moment.
> To find application programming errors that unnecessarily consume a lot of memory,
> we start a relatively large number of JVMs, give them little memory (Xmx), and set -XX:+HeapDumpOnOutOfMemoryError.
> If a session needs a lot of memory briefly, and the JVM throws an OutOfMemoryError, then we have a dump and can examine it.
> 
> Example:
> We start 4 JVMs with Xmx=1GB. If there is exactly 1 session and it briefly requests 1.5GB of memory due to an application error
> then there is an OutOfMemoryError, and we have a HeapDump.
> If we were to run only 1 JVM with Xmx=4GB, then in this case, there would be no OutOfMemoryError, and everything would continue to run.
> Which is actually not bad for the user. However, we find fewer memory problems in our application code this way.
> Because normally, a session needs about 16MB. Of course, there are certain processes that require many times that amount of memory briefly.
> For example, when a session does a payroll run, it might need 50MB of memory for a short time.
> 
> I wanted to ask how others might be doing this. What we are already doing is collecting and monitoring metrics.
> 
> An idea that we have, and which would be very practical for us, is if there were a kind of "soft memory threshold" for the JVM/GC.
> The JVM/GC would then try not to exceed this. If it has to, then the same mechanisms would be useful as for "OnOutOfMemoryError".
> So, no OutOfMemoryError would be thrown, but the JVM could allocate the memory, but a one-time event would be triggered, for example "OnOutOfSoftMemory".
> Analogous to -XX:+HeapDumpOnOutOfMemoryError, there could then be an option -XX:+HeapDumpOnOutOfSoftMemory where a HeapDump is generated.
> Or a -XX:OnOutOfSoftMemory=string to execute a command or script.
> 
> Concrete example:
> The JVM could be set with for example a "SoftXmx=1GB", a "Xmx=2GB", and a -XX:+HeapDumpOnOutOfSoftMemory.
> If we think back to the case from above where 1 session briefly requests 1.5GB of memory,
> then a HeapDump would be created, but everything would continue to run normally.
> 
> Now I wanted to ask if such a feature would be conceivable and what your general thoughts are on it.
> 
> Thank you very much,
> 
> Regards,
> Reto Merz
> 


From jwaters at openjdk.org  Thu May  8 21:43:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 21:43:02 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <3JOhI_-acxlyIreUPgbY5reRbuy4o0Rdh99q9JDgkfw=.0d792d1c-b156-46e2-aa80-3c07d3c183fe@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2864379663

From dholmes at openjdk.org  Thu May  8 22:01:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 May 2025 22:01:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

> we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). 

No, because that is an internal implementation detail.

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

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2864508184

From sspitsyn at openjdk.org  Thu May  8 22:07:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 May 2025 22:07:40 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v3]
In-Reply-To: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
Message-ID: <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>

> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>  
>  Testing:
>   - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: added comment with clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25060/files
  - new: https://git.openjdk.org/jdk/pull/25060/files/c4d167c4..b61ff511

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

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

PR: https://git.openjdk.org/jdk/pull/25060

From sspitsyn at openjdk.org  Thu May  8 22:07:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 May 2025 22:07:40 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v2]
In-Reply-To: <B3YiX6wC9Pg_ntkYl-oGLCjQTHEDK_NJTCkugE2p3n8=.b27575c8-68b4-4459-a861-1de46cf180fb@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <ZOzohb7yhkYgXFGf8U4uwICgJcJmxSd-5UtX5Kw0qqs=.82adba05-4f94-48b0-a736-7750073ac307@github.com>
 <lSdXMS_XmUFpNYiCOvD5XEYjfh4T1xWQLiSXbJYee1k=.13bcf23d-9d05-42e9-ae20-00334654b14a@github.com>
 <Wo1f8BmKGt_LihNHZJIHS4vwuP0tT0-h3kyIbKFHrN0=.3eb020ed-a888-485b-b8e5-78612e491ad7@github.com>
 <B3YiX6wC9Pg_ntkYl-oGLCjQTHEDK_NJTCkugE2p3n8=.b27575c8-68b4-4459-a861-1de46cf180fb@github.com>
Message-ID: <shuWPS39432TJ7sK8vq7H5wz2DaINQMweOHPiE4Ig_w=.e6565f07-c18f-4569-989f-6df9359e4523@github.com>

On Thu, 8 May 2025 18:24:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Yes. Maybe with the declaration.

Thanks. Added a comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2864537210

From dholmes at openjdk.org  Thu May  8 22:09:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 May 2025 22:09:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <eK7I7glqgviACe1Wo_e-k_Z05hPYj1sAvsCBBYpN3MI=.946b59b4-c9aa-4d02-8993-9b948b679946@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826465546

From cjplummer at openjdk.org  Thu May  8 22:16:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 8 May 2025 22:16:33 GMT
Subject: RFR: 8356588: Some nsk/jdi tests can fetch ThreadReference from static
 field in the debuggee: part 3
Message-ID: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>

There were a small number of tests that were missed with [JDK-8356023](https://bugs.openjdk.org/browse/JDK-8356023) (part 2). Most of these tests are ones that were calling vm.allThreads() directly to search for the needed thread rather than relying on findThreadByNameOrThrow().

Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

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

Commit messages:
 - fix jcheck errors
 - update copyrights
 - threadNames[] not needed anymore
 - Use threadByFieldNameOrThrow() when possible

Changes: https://git.openjdk.org/jdk/pull/25132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356588
  Stats: 428 lines in 35 files changed: 75 ins; 272 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/25132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25132/head:pull/25132

PR: https://git.openjdk.org/jdk/pull/25132

From cjplummer at openjdk.org  Thu May  8 22:59:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 8 May 2025 22:59:52 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v3]
In-Reply-To: <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
Message-ID: <ytyMPjsG6kLcNQdkTthfe_srZYC37QVWPTF5TVDXOYM=.ef25b0d8-3a73-421b-a80c-ea9b7954eb96@github.com>

On Thu, 8 May 2025 22:07:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added comment with clarification

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25060#pullrequestreview-2826558437

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From liach at openjdk.org  Thu May  8 23:20:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:20:06 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v2]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <A-LMS1555NFlB8bzeeHOHFKmxGGx3H1OqygrYdoed9Y=.115faa5c-d7f4-4a0a-8512-33bbfdae6e37@github.com>

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Use classfile api instead of javac setting version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/b8fa795e..cb02b045

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

  Stats: 324 lines in 10 files changed: 30 ins; 180 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From liach at openjdk.org  Thu May  8 23:46:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:46:35 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v3]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <yxdzxJS9OWbe0xEWHSjft58dQLbALFQ-enkP92Or6_c=.440fd958-57d9-400b-962b-9f851d5c904d@github.com>

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Use classfile api instead of javac setting version
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - 8356548: Avoid using ASM to parse latest class files in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/cb02b045..3114f523

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

  Stats: 2043 lines in 169 files changed: 705 ins; 957 del; 381 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From lmesnik at openjdk.org  Fri May  9 00:25:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:25:52 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v3]
In-Reply-To: <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
Message-ID: <P1ZFsrnTuT41P43YHglx46a68Y3KJlpU6WGoQeFid0Y=.6cffc809-39a6-4f85-8452-c30c93754065@github.com>

On Thu, 8 May 2025 22:07:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added comment with clarification

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25060#pullrequestreview-2826655094

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From iklam at openjdk.org  Fri May  9 03:59:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 03:59:08 GMT
Subject: RFR: 8356595 convert cds log to aot log
Message-ID: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>

This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 

We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.

Please see **aotLogging.hpp** for how the macros work.

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

Commit messages:
 - @stefank suggestions
 - Merge remote-tracking branch '8355638-xlog-aot-as-alias-for-xlog-cds' into 8355638-xlog-aot-as-alias-for-xlog-cds-alt-impl
 - Removed checks for error message that got removed from the PR
 - Reverted unrelated changes in filemap.cpp
 - @vnkozlov and @dholmes-ora comments
 - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds
 - cds+aot+load -> aot+load
 - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds
 - @jdksjolen comment
 - Fixed comment
 - ... and 10 more: https://git.openjdk.org/jdk/compare/52a5583d...b7670bf0

Changes: https://git.openjdk.org/jdk/pull/25136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356595
  Stats: 695 lines in 42 files changed: 320 ins; 13 del; 362 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From iklam at openjdk.org  Fri May  9 06:27:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 06:27:38 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v2]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <4aTAnrjgLBVGyOkzWub87lIMm8YxuA6HWAs9JTU2JJk=.967f32e8-0577-4817-b0c5-964f4ac79566@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed macos build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/b7670bf0..dbab9a7e

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

  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From alanb at openjdk.org  Fri May  9 06:34:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 06:34:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2827165376

From alanb at openjdk.org  Fri May  9 06:34:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 06:34:52 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
 <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>
Message-ID: <GrTeVQOpUqy5D8KZ2sI6IcVWbhTtCLiEk1-gaNj0Qb0=.ba95f998-c45a-41c8-98df-1d9261c8648c@github.com>

On Thu, 8 May 2025 19:49:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:
>> 
>>> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
>>> 98:         awaitBlocked(thread1, reached1);
>>> 99:         awaitBlocked(thread2, reached2);
>> 
>> This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 
>> 
>> An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.
>
> Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead.
> 
> Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is.

Okay, I think what you have is good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2081022353

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From rvansa at openjdk.org  Fri May  9 07:38:54 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 May 2025 07:38:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <TnhMzJu7axls4dxRQAAgkRGV7MCmBVQJ0cPM6_e_83k=.fc83eca8-88c7-446b-a849-d71b40aeaa82@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <szJF_YgQLulgWpyGDcJ_6e-7LJ__Vj2OMe_2sGvTepQ=.5f2339e3-4018-4a9c-b6cc-bcf4aecc948d@github.com>
 <GRNMB4WXbu0OY09VE-PITDP9rLin4TsPAekeLN7fCQw=.2523ac42-fe86-48e4-9050-49ba51dd43a3@github.com>
 <TnhMzJu7axls4dxRQAAgkRGV7MCmBVQJ0cPM6_e_83k=.fc83eca8-88c7-446b-a849-d71b40aeaa82@github.com>
Message-ID: <Mc4981p33crT4hoL0tixLBW4YZuf2pt9tgjLOAmZ3OA=.b91c752e-e8cb-4861-9776-3e2aa070b173@github.com>

On Wed, 7 May 2025 19:18:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Compressing the fields into unsigned5 and decoding them into streams was quite a complicated change but manageable because the interface to decode them is all one has write the FieldStream iterator. This is hard to review.

Not sure if I got you right, but I agree that the interface should not be changed (significantly). Here I am adding `skip_fields_until` method for one place; to me it was a bit surprising that there was not focus on (sub-linear) lookup from the beginning.

> I'm wondering how much of a problem this is in real code, other than the case with 21k fields and if there's a way to programmatically work around this case, like decompress the fields into a hashtable or something (?) It would be interesting to see some histograms of some corpus Java code (maybe put this info in the associated bug).

The customer code that hit the regression looked to me as something generated, probably already working around some sizing limits, and the problem was in an initialization routine setting up thousands of descriptors. I am not saying that it could not be reworked for the better, but for someone this is an order of magnitude regression and I understand that they demand fix on JDK side.
What kind of histogram would you imagine? I could count the number of fields in those 10 classes...

> Fred tells me that we already store the original field index so maybe above is moot.

Could you be more specific, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2865480638

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From sspitsyn at openjdk.org  Fri May  9 08:41:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 May 2025 08:41:57 GMT
Subject: RFR: 8356251: Need minor cleanup for interp_only_mode [v3]
In-Reply-To: <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
 <nHY8XD2Ml5QyopLujl7zh2JuRWnHQefq8JaZg-s7w4o=.b871dcc9-71d9-457a-8987-0e6ed9311833@github.com>
Message-ID: <OwBBFx0LXrQdDsAF_5P5j3xQnSc619udwLgsiFNXQ2U=.f9f39563-fb43-49ae-ac85-935e57b72fdb@github.com>

On Thu, 8 May 2025 22:07:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>  
>>  Testing:
>>   - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added comment with clarification

Thank you for review, Chris and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/25060#issuecomment-2865679917

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From coleenp at openjdk.org  Fri May  9 12:22:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 May 2025 12:22:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <j8yURw5WLZUzMk8tLV0PDPMoWlz_JAifrSVCIpy8UVk=.d22bb5a8-21f6-4a16-9b0e-c75bfdd227cd@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

I'm still working on understanding this change and figuring out why I'm getting a crash that reports


#  assert(compare_symbols(fields->adr_at(i - 1)->name(constants), fields->adr_at(i)->name(constants)) < 0) failed: Fields should be sorted


I can't reproduce this crash locally yet.

Also trying to find how it reports the declaration order of fields for JVMTI.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2866338427

From sspitsyn at openjdk.org  Fri May  9 12:26:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 May 2025 12:26:58 GMT
Subject: Integrated: 8356251: Need minor cleanup for interp_only_mode
In-Reply-To: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
References: <P-mLGZ_4TaKUseQkg_oe6TyPJZEf6fZkYGdIa2uyIbE=.0ee08795-1d2e-482a-8178-8432677ddb8c@github.com>
Message-ID: <DQ9hiONsgaAA0PXGkAeW9pnmtqmHmN390Ap8DjNEMYY=.f36caac0-e8c3-403d-8791-9faf6340d35b@github.com>

On Tue, 6 May 2025 08:29:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor cleanup for the JVMTI `interp_only_mode` implementation which includes the following changes:
>  - The `interp_only_mode` in `JavaThread` is represented with a counter which is incremented and decremented. This is confusing because this value should only take values `0` or `1`. Asserts are placed to make sure it is never going out of bounds. The `interp_only_mode` in a `JavaThread` is checked by the interpreter chunks which expect it to be an `integer`. This cleanup has no intention to make it a boolean.
>  - The function `JvmtiThreadState::process_pending_interp_only()` does a sync on the `JvmtiThreadState_lock` which is not really needed and is being removed. It is called in a `VTMS` transition and so, can not clash with the `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>  
>  Testing:
>   - TBD: Mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 411a63ea
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/411a63ea1b0c6e8bfea219427bf1c317c5dadabf
Stats:     20 lines in 4 files changed: 3 ins; 8 del; 9 mod

8356251: Need minor cleanup for interp_only_mode

Reviewed-by: lmesnik, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/25060

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From ihse at openjdk.org  Fri May  9 14:20:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 14:20:31 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
Message-ID: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>

A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.

While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.

I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

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

Commit messages:
 - 8356644: Update encoding declaration to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356644
  Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod
  Patch: https://git.openjdk.org/jdk/pull/25148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25148/head:pull/25148

PR: https://git.openjdk.org/jdk/pull/25148

From pchilanomate at openjdk.org  Fri May  9 15:07:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:59 GMT
Subject: Integrated: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <vDmLNPc2R36mJlMHNJtn7EXVtQo5aptN9G_z-VQCJn4=.eca13064-7eda-4f32-ab59-6d1d2488e0aa@github.com>

On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 9ebb5d42
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ebb5d42d43a743cf3a5197c7dabe46ac8120474
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

Reviewed-by: kevinw, dholmes, alanb

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

PR: https://git.openjdk.org/jdk/pull/25119

From pchilanomate at openjdk.org  Fri May  9 15:07:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:57 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
 <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>
Message-ID: <WCjH2ad94orGe9oWN5J5ylcX2IUYuVtEOr6gHVZrNyw=.fb8f3818-17ea-46ad-acb1-f3307e43c687@github.com>

On Thu, 8 May 2025 21:59:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly().
> 
> No, because that is an internal implementation detail. It is a grey area. There is no such thing as an uninterruptible-wait in the Java language, so if we marked the thread as waiting and yet it failed to stop waiting if interrupted, then that would appear to be a bug.
>
I see, thanks for the clarification David.

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

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866895215

From pchilanomate at openjdk.org  Fri May  9 15:07:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:58 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
 <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>
Message-ID: <0YcCb_ThphXvVjENLXPNn-Z5EKdj_VIUKKAWPYdOc04=.f5571a2c-9afb-4a34-b13c-abb530e64960@github.com>

On Fri, 9 May 2025 06:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename awaitBlocked to awaitTrueAndBlocked
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the reviews @AlanBateman, @kevinjwalls and @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866899837

From dfuchs at openjdk.org  Fri May  9 16:01:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 16:01:51 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <xYLb16pp1-tzU59PSQJwkT13-nO_nm6t51FoewRQkEc=.943e14e7-46c2-4620-83c9-b5557b7480ae@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Changes to net-properties.html LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2828873053

From iklam at openjdk.org  Fri May  9 17:45:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 17:45:08 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  More conversion; clean up; bug fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/dbab9a7e..e2156fbe

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

  Stats: 73 lines in 11 files changed: 16 ins; 25 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From prr at openjdk.org  Fri May  9 20:53:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:53:52 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <Smz6J8OkGf1azxvWU7doxgpYm42StyU8_196s8ZNmGU=.70a7da27-72e6-40dc-81b0-c57f65d4cfdc@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829627877

From cjplummer at openjdk.org  Fri May  9 21:04:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 May 2025 21:04:03 GMT
Subject: RFR: 8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java fails
 sometimes on macOS
Message-ID: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>

We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.

Tested by running test on all supported platforms.

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

Commit messages:
 - add the listener after the VMStart has arrived

Changes: https://git.openjdk.org/jdk/pull/25156/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356641
  Stats: 9 lines in 1 file changed: 6 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25156/head:pull/25156

PR: https://git.openjdk.org/jdk/pull/25156

From coleenp at openjdk.org  Fri May  9 21:24:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 May 2025 21:24:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <hnOi9l520OUh3t-mym8ZGBSP3t2BCckeqTmk74i3zQ8=.a02c2d38-b774-4460-8494-7df6fc4e1958@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

84	      assert(compare_symbols(fields->adr_at(i - 1)->name(constants), fields->adr_at(i)->name(constants)) < 0, "Fields should be sorted");

Happens with names matching (not signatures).  How does the same name for two fields work if it spans a JUMP_TABLE_STRIDE?

This should add some tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2867901984

From liach at openjdk.org  Fri May  9 22:34:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 22:34:45 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v4]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

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

 - Move other tier 4,5, etc tests to not use ClassReader
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Use classfile api instead of javac setting version
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - 8356548: Avoid using ASM to parse latest class files in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/3114f523..4fc1b513

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=02-03

  Stats: 2021 lines in 102 files changed: 1232 ins; 449 del; 340 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From naoto at openjdk.org  Fri May  9 23:18:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 23:18:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <UqQ7Tm8xYaIcxM4GvA9ISQi7kDMs1WwuEvbC2kRo1CQ=.a38e9c07-04dd-4fba-a118-4afd33951c06@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829881137

From liach at openjdk.org  Sat May 10 14:32:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 14:32:57 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v4]
In-Reply-To: <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
Message-ID: <qmoVPMrfmoJZGBLO__liBf63mx4c9bX5UNPcp-XCH2s=.33d0d9cd-45d4-4876-891c-00d64c9fb6a4@github.com>

On Fri, 9 May 2025 22:34:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move other tier 4,5, etc tests to not use ClassReader
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Use classfile api instead of javac setting version
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - 8356548: Avoid using ASM to parse latest class files in tests

Testing: hs-tier 1-5

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

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-2868920846

From iklam at openjdk.org  Sun May 11 05:13:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 11 May 2025 05:13:17 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
Message-ID: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>

https://openjdk.org/jeps/483 mentions:

> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.

However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,


$ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
Error occurred during CDS dumping
Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping


With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.

With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:

-  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.

- In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

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

Commit messages:
 - fixed whitespace
 - 8356693: AOT assembly phase fails with -javaagent
 - step1

Changes: https://git.openjdk.org/jdk/pull/25170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356693
  Stats: 259 lines in 12 files changed: 253 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25170/head:pull/25170

PR: https://git.openjdk.org/jdk/pull/25170

From gli at openjdk.org  Sun May 11 19:33:58 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 11 May 2025 19:33:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <ZqppdasCApR5hBmr8BkQeF2eQgd4G6QheLttH4Xu1dU=.3aee27ee-7335-42c5-98df-0c4d1e3491f6@github.com>

On Fri, 2 May 2025 10:23:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

I review about 1/3 code now. But I want to save the thoughts, so I submit it. Sorry for the noise if it bothers you.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:

> 341:       if (is_gc_overhead_limit_reached()) {
> 342:         return nullptr;
> 343:       }

It seems the parameter `gc_overhead_limit_was_exceeded` and the field `MemAllocator::Allocation::_overhead_limit_exceeded` are not used by all GCs now. Should we keep the parameter and set it as `true` under the condition `is_gc_overhead_limit_reached()`? For example:


      if (op.prologue_succeeded()) {
        assert(is_in_or_null(op.result()), "result not in heap");
        if (is_gc_overhead_limit_reached()) {
          *gc_overhead_limit_was_exceeded = true;
          return nullptr;
        }
        return op.result();
      }


Or we should remove the parameter and the field in another PR.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 825:

> 823:   // If MinHeapFreeRatio is at its default value; shrink cautiously. Otherwise, users expect prompt shrinking.
> 824:   if (FLAG_IS_DEFAULT(MinHeapFreeRatio) && MinHeapFreeRatio == 0) {
> 825:     if (desired_capacity < current_capacity) {

I think curiously a lot about the condition `MinHeapFreeRatio == 0` and then I find the following code in `parallelArguments.cpp`. May it be better to use `UseAdaptiveSizePolicy && FLAG_IS_DEFAULT(MinHeapFreeRatio)` here instead of `FLAG_IS_DEFAULT(MinHeapFreeRatio) && MinHeapFreeRatio == 0`?


  if (UseAdaptiveSizePolicy) {
    // We don't want to limit adaptive heap sizing's freedom to adjust the heap
    // unless the user actually sets these flags.
    if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) {
      FLAG_SET_DEFAULT(MinHeapFreeRatio, 0);
    }
    if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) {
      FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100);
    }
  }

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 862:

> 860:   resize_old_gen_after_full_gc();
> 861:   young_gen()->resize_after_full_gc();
> 862: }

The `PSYoungGen` has its methods `resize_after_full_gc` and `resize_after_young_gc`. I think such design is good. What about moving the method `resize_old_gen_after_full_gc` (and the related method `calculate_desired_old_gen_capacity`) to `PSOldGen` and renaming it as `resize_after_full_gc`?

src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 141:

> 139:   // Invoked at gc-pause-end
> 140:   void gc_epilogue(bool full);
> 141: 

It is strange that Parallel GC didn't have its prologue and epilogue before. And currently, the concrete work categories (such as increasing the GC count) of the prologue and epilogue in all the GCs are not unified. It seems an issue left over by history, so it need more investigation in the future.

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 45:

> 43:      _avg_promoted(new AdaptivePaddedNoZeroDevAverage(AdaptiveSizePolicyWeight, PromotedPadding)),
> 44:      _space_alignment(space_alignment),
> 45:      _young_gen_size_increment_supplement(YoungGenerationSizeSupplement) {}

Typos in `gc_globals.hpp`(shown below): `YoungedGenerationSizeIncrement` and `YoungedGenerationSizeSupplement`. It should be fixed in another PR.

  product(uint, YoungGenerationSizeIncrement, 20,                           \
          "Adaptive size percentage change in young generation")            \
          range(0, 100)                                                     \
                                                                            \
  product(uint, YoungGenerationSizeSupplement, 80,                          \
          "Supplement to YoungedGenerationSizeIncrement used at startup")   \ // <--- here
          range(0, 100)                                                     \
                                                                            \
  product(uintx, YoungGenerationSizeSupplementDecay, 8,                     \
          "Decay factor to YoungedGenerationSizeSupplement")                \ // <--- here
          range(1, max_uintx)                                               \

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1104:

> 1102:     heap->post_full_gc_dump(&_gc_timer);
> 1103: 
> 1104:     size_policy->record_gc_pause_end_instant();

What about moving this invocation into `major_collection_end`? Just like the `record_gc_pause_start_instant` and `major_collection_begin`.

src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 179:

> 177:     _gc_distance_timer.reset();
> 178:     _gc_distance_timer.start();
> 179:   }

The method name `record_gc_pause_end_instant` is about `gc pause`, but the code is about `gc distance`. May we need a clearer name?

src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 184:

> 182:     _gc_distance_timer.stop();
> 183:     _gc_distance_seconds_seq.add(_gc_distance_timer.seconds());
> 184:   }

The method name `record_gc_pause_start_instant` is about `gc pause`, but the code is about `gc distance`. May we need a clearer name?

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

Changes requested by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2831414868
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083540517
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083573645
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083574866
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083578247
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083595212
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083596481
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083582694
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2083581870

From rvansa at openjdk.org  Mon May 12 06:26:53 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 12 May 2025 06:26:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <hnOi9l520OUh3t-mym8ZGBSP3t2BCckeqTmk74i3zQ8=.a02c2d38-b774-4460-8494-7df6fc4e1958@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <hnOi9l520OUh3t-mym8ZGBSP3t2BCckeqTmk74i3zQ8=.a02c2d38-b774-4460-8494-7df6fc4e1958@github.com>
Message-ID: <s4Id0x5pO7R6JgAwtdchou4wUJFfq2tyB70y37EhPoo=.6df4fb80-ad39-4b91-9705-fba2fa20e097@github.com>

On Fri, 9 May 2025 21:22:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ```
> 84	      assert(compare_symbols(fields->adr_at(i - 1)->name(constants), fields->adr_at(i)->name(constants)) < 0, "Fields should be sorted");
> ```
> 
> Happens with names matching (not signatures). How does the same name for two fields work if it spans a JUMP_TABLE_STRIDE?
> 
> This should add some tests.

The stream contains 'declared fields', not including superclass... How could two names match?

https://docs.oracle.com/javase/specs/jls/se17/html/jls-8.html#jls-8.3

> It is a compile-time error for the body of a class declaration to declare two fields with the same name. 

Is this some generated code that breaks JLS?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2871010896

From coleenp at openjdk.org  Mon May 12 12:40:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 May 2025 12:40:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <S7xIV1dxerPa26zk1AshowKZcFSnadjmg865F3y7aKo=.99a65985-b469-42b1-baa8-50f681aecd7c@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

One test that it failed on is  trying to load a class where the number of fields of a class is equal to 65535.  It's a JCK test.  Do you have JCK tests or you could write this one?  It's not a negative test for static/non-static field name matching (what I thought on Friday). I'm trying to get it to print the growable array before the exception but that crashes on two things.  One needs is_contended() conditional in the print statement, but still debugging why it crashes now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2872394286

From kevinw at openjdk.org  Mon May 12 13:37:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 12 May 2025 13:37:54 GMT
Subject: RFR: 8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java
 fails sometimes on macOS
In-Reply-To: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
References: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
Message-ID: <JwJeK3mIBZfjfBL01ZOihG0HdSijAUaOA9fBft4uqCw=.fcc8398e-8c08-431a-9b19-9f979224b03c@github.com>

On Fri, 9 May 2025 20:59:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.
> 
> Tested by running test on all supported platforms.

Sounds good to me!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25156#pullrequestreview-2833254792

From rvansa at openjdk.org  Mon May 12 15:12:52 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 12 May 2025 15:12:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <S7xIV1dxerPa26zk1AshowKZcFSnadjmg865F3y7aKo=.99a65985-b469-42b1-baa8-50f681aecd7c@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <S7xIV1dxerPa26zk1AshowKZcFSnadjmg865F3y7aKo=.99a65985-b469-42b1-baa8-50f681aecd7c@github.com>
Message-ID: <NCBjm2d05H2LCE_9VLSxHEogWOsJcv_hd1twGNzp-9E=.3b91b55e-46c7-4d65-b9b9-99c0b01f5285@github.com>

On Mon, 12 May 2025 12:38:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> One test that it failed on is trying to load a class where the number of fields of a class is equal to 65535. It's a JCK test. Do you have JCK tests or you could write this one?

You mean replicating the JCK testing logic into regular testsuite? I could do that, which test is that for reference? I wonder how that fails when the fields are only reordered, nothing is added.

However, while [class format](https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1) technically supports up to 65535 fields, I believe that we are also limited by the constant pool holding no more than 65535 entries, where some space would be occupied by the type field type, there's the dummy index 0 and there might be further records so we won't get as high. I think that normally `javac` does not de-duplicate the signature record, so this might require some handcrafting. Maybe the JCK test reuses some names to form a different combo (which could be valid from JVMS POV but not JLS?) to max it out at 65535 fields?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2872968852

From coleenp at openjdk.org  Mon May 12 16:02:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 May 2025 16:02:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <BPZ7QHWpgtBxZgpRMxxeuNaQqGbg49AfOiOtmlRkaxY=.d230fb49-a479-44d7-aa1e-6fee47488084@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

The test is vm/classfmt/lmt/fldnum001/fldnum00101m1/fldnum00101m1.html . I don't know why it fails.

I don't think you should duplicate this test in the JDK test base, but if you don't have the JCK it's easy to write yourself for debugging purposes.  It doesn't look like it reuses field names even though that's what I see in the core file.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2873139545

From kvn at openjdk.org  Mon May 12 16:14:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 12 May 2025 16:14:57 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v14]
In-Reply-To: <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
Message-ID: <F7cKiJ5a16421sl3dukg3m878OfsGld5MXxJbIxI_OU=.47a3d27c-8403-4425-b133-fc96b964b9e1@github.com>

On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833790759

From cjplummer at openjdk.org  Mon May 12 16:48:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 12 May 2025 16:48:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <puTVwlJMNUEAZ9b51LZPeCe0MsCYsg3eEADp987VC8A=.673dc352-b4b2-4ad6-a537-eef93eb8ed9b@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

Changes requested by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2833873059

From cjplummer at openjdk.org  Mon May 12 16:48:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 12 May 2025 16:48:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <-Xq9NUkXDnlFyKgh2juvL8zOFSxtc7AhEVBxfxo6w0Y=.2a611ac0-aca3-4ba6-beff-fb3daddba57a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <lPiL1w0niscLkd_gobnhSOj3RIxCew4-iz6noaZoFM4=.2d277009-1dab-43d5-9dcc-d349aa784d6b@github.com>
 <-Xq9NUkXDnlFyKgh2juvL8zOFSxtc7AhEVBxfxo6w0Y=.2a611ac0-aca3-4ba6-beff-fb3daddba57a@github.com>
Message-ID: <fGgYbXmabJ3gC-onCzDCwpf6KC0BzNf-EkbePClYsFY=.0686d1b1-44a8-4115-968a-b87824e17103@github.com>

On Mon, 5 May 2025 06:27:19 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.hpp line 223:
>> 
>>> 221: };
>>> 222: 
>>> 223: #define JUMP_TABLE_STRIDE 16
>> 
>> How was the threshold of 16 determined?
>
> I haven't done any benchmarks looking for the optimal value; this should balance the extra memory footprint vs. improved performance. Also I was hoping to not affect the bulk of Java code; rather optimize "big" classes that show degraded performance due to O(N) lookup.
> How exactly could the optimization function look like if we're to weigh in both memory consumption and execution speed?

Since this is also referenced by SA, it should be exported in vmStructs and not also defined separately in SA. I believe that you can use something like ObjectMonitor::ANONYMOUS_OWNER as an example of how to do this:

In hotspot:
  static const int64_t ANONYMOUS_OWNER = 1;

In vmstructs:
  declare_constant(ObjectMonitor::ANONYMOUS_OWNER)                        \

In SA:
    ANONYMOUS_OWNER = db.lookupLongConstant("ObjectMonitor::ANONYMOUS_OWNER").longValue();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2085073329

From shade at openjdk.org  Mon May 12 16:55:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 May 2025 16:55:53 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <h6-u5z_jI9f19yIj_KGncev-3KYRdJOYstcJrxD1bJk=.d21ab466-f001-421c-b4c0-9f0c68133d56@github.com>

On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

src/hotspot/share/prims/jvmtiAgent.cpp line 588:

> 586:     // Agents are allowed with -XX:AOTMode=record and -XX:AOTMode=on/auto.
> 587:     // Agents are completely disabled when -XX:AOTMode=create
> 588:     assert(!CDSConfig::is_dumping_final_static_archive(), "agents should have been disabled with -XX:AOTMode=create");

Is there a point in asserting this? I am thinking users would pass the same command line to `-XX:AOTMode=create` without thinking twice. And since we are doing the right thing, ignoring the agents, it seems we "only" need to print the user-visible warning. Maybe not even that, and just return?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2084856035

From iklam at openjdk.org  Mon May 12 17:20:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 May 2025 17:20:56 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v14]
In-Reply-To: <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
Message-ID: <igPa9ra_wxavTe1aZDK5sZdyb047kXXrhehfefCBOdY=.b916141a-9d05-4f2b-b1f0-850d3d9ab766@github.com>

On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

LGTM. Small nits about logging and testing.

src/hotspot/share/cds/filemap.cpp line 1955:

> 1953:                     " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type,
> 1954:                     _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries);
> 1955:       return false;

The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`.  (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807))

Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833939411
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085115469

From iklam at openjdk.org  Mon May 12 17:23:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 May 2025 17:23:54 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <h6-u5z_jI9f19yIj_KGncev-3KYRdJOYstcJrxD1bJk=.d21ab466-f001-421c-b4c0-9f0c68133d56@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <h6-u5z_jI9f19yIj_KGncev-3KYRdJOYstcJrxD1bJk=.d21ab466-f001-421c-b4c0-9f0c68133d56@github.com>
Message-ID: <sbmkdIpqB1S-3k-iD1AEtup1_1MFMD32msbSlWyu0kM=.048e0eb0-9cc1-4e6a-a807-9029cf2a026b@github.com>

On Mon, 12 May 2025 14:46:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> https://openjdk.org/jeps/483 mentions:
>> 
>>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
>> 
>> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
>> 
>> 
>> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
>> Error occurred during CDS dumping
>> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
>> 
>> 
>> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
>> 
>> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
>> 
>> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
>> 
>> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.
>
> src/hotspot/share/prims/jvmtiAgent.cpp line 588:
> 
>> 586:     // Agents are allowed with -XX:AOTMode=record and -XX:AOTMode=on/auto.
>> 587:     // Agents are completely disabled when -XX:AOTMode=create
>> 588:     assert(!CDSConfig::is_dumping_final_static_archive(), "agents should have been disabled with -XX:AOTMode=create");
> 
> Is there a point in asserting this? I am thinking users would pass the same command line to `-XX:AOTMode=create` without thinking twice. And since we are doing the right thing, ignoring the agents, it seems we "only" need to print the user-visible warning. Maybe not even that, and just return?

If someone removes the call to `JvmtiAgentList::disable_agent_list()`, we will come to here and exit the JVM. This assert is to guard against that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2085127224

From shade at openjdk.org  Mon May 12 17:58:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 May 2025 17:58:52 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <sbmkdIpqB1S-3k-iD1AEtup1_1MFMD32msbSlWyu0kM=.048e0eb0-9cc1-4e6a-a807-9029cf2a026b@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <h6-u5z_jI9f19yIj_KGncev-3KYRdJOYstcJrxD1bJk=.d21ab466-f001-421c-b4c0-9f0c68133d56@github.com>
 <sbmkdIpqB1S-3k-iD1AEtup1_1MFMD32msbSlWyu0kM=.048e0eb0-9cc1-4e6a-a807-9029cf2a026b@github.com>
Message-ID: <LBGZqtl-z91Vp0omf7o3TdTd-yELP41HlGp0jQJAW-4=.92275d7b-491b-428e-8887-64dbcb505490@github.com>

On Mon, 12 May 2025 17:21:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiAgent.cpp line 588:
>> 
>>> 586:     // Agents are allowed with -XX:AOTMode=record and -XX:AOTMode=on/auto.
>>> 587:     // Agents are completely disabled when -XX:AOTMode=create
>>> 588:     assert(!CDSConfig::is_dumping_final_static_archive(), "agents should have been disabled with -XX:AOTMode=create");
>> 
>> Is there a point in asserting this? I am thinking users would pass the same command line to `-XX:AOTMode=create` without thinking twice. And since we are doing the right thing, ignoring the agents, it seems we "only" need to print the user-visible warning. Maybe not even that, and just return?
>
> If someone removes the call to `JvmtiAgentList::disable_agent_list()`, we will come to here and exit the JVM. This assert is to guard against that.

OK, that makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2085175665

From iveresov at openjdk.org  Mon May 12 19:29:18 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 12 May 2025 19:29:18 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v15]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into pp2
 - Address review comments
 - Merge branch 'master' into pp2
 - Fix compile
 - Fix additional issues
 - Make sure command line flags that affect MDO layout are consistent
 - Fix semantics change from the previous commit
 - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type
 - Fix flag behavior
 - Fix log tags
 - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14
  Stats: 3226 lines in 59 files changed: 3011 ins; 100 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From heidinga at openjdk.org  Mon May 12 20:05:55 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 12 May 2025 20:05:55 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v15]
In-Reply-To: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com>
Message-ID: <931WapeeMqp8gbb720PmF0inR4k_kD9CL9UL9SGDyWY=.2406d164-dc7e-49ce-9e26-78f0a7f3f9e6@github.com>

On Mon, 12 May 2025 19:29:18 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into pp2
>  - Address review comments
>  - Merge branch 'master' into pp2
>  - Fix compile
>  - Fix additional issues
>  - Make sure command line flags that affect MDO layout are consistent
>  - Fix semantics change from the previous commit
>  - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type
>  - Fix flag behavior
>  - Fix log tags
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887

src/hotspot/share/cds/filemap.hpp line 120:

> 118:   bool    _compressed_class_ptrs;                 // save the flag UseCompressedClassPointers
> 119:   int     _narrow_klass_pointer_bits;             // save number of bits in narrowKlass
> 120:   int     _narrow_klass_shift;                    // save shift width used to pre-compute narrowKlass IDs in archived heap objectsa

Suggestion:

  int     _narrow_klass_shift;                    // save shift width used to pre-compute narrowKlass IDs in archived heap objects


Minor typo, don't bother fixing if it will result in a re-review cycle

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085360465

From cjplummer at openjdk.org  Mon May 12 21:06:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 12 May 2025 21:06:13 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from static
 field in the debuggee: part 4
Message-ID: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>

This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().

Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 

Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.

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

Commit messages:
 - fix jcheck errors
 - update copyrights
 - minor fixes
 - Add and use new threadByFieldName() APIs
 - Use threadByFieldNameOrThrow()

Changes: https://git.openjdk.org/jdk/pull/25190/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25190&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356811
  Stats: 592 lines in 74 files changed: 253 ins; 90 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/25190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25190/head:pull/25190

PR: https://git.openjdk.org/jdk/pull/25190

From iveresov at openjdk.org  Mon May 12 21:30:12 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 12 May 2025 21:30:12 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v16]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <QpBysGRRYuDnbr2NNK1E4ivZ1pXOby5C-XJ5AhjUsK0=.c5d73094-9c6f-4359-8ae9-8e4279e47c2c@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Make the test permute through default flag values too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/ae332887..d75cb5dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14-15

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

PR: https://git.openjdk.org/jdk/pull/24886

From coleenp at openjdk.org  Mon May 12 21:36:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 May 2025 21:36:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <3uxxwU4JhY2OG3vQR4o22oYfvlpPLbOO4XXDuA03QJ4=.a9745a21-aae8-48f2-8248-240384067250@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

4.5. Fields
Each field is described by a field_info structure.

No two fields in one class file may have the same name and descriptor ([?4.3.2](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.3.2)).


Fields can have the same name in the JVMS, just not the JVMLS.  The JVM checks for duplicate name AND signatures.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2874207844

From amenkov at openjdk.org  Mon May 12 23:44:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 12 May 2025 23:44:51 GMT
Subject: RFR: 8356588: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 3
In-Reply-To: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
References: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
Message-ID: <uyTCOwvQKTIz4ayKmn1yQ1Q6oCv9zLw8l5DEIs5j9ZE=.61da24bb-2f34-4173-976b-c20112ac8d4f@github.com>

On Thu, 8 May 2025 21:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There were a small number of tests that were missed with [JDK-8356023](https://bugs.openjdk.org/browse/JDK-8356023) (part 2). Most of these tests are ones that were calling vm.allThreads() directly to search for the needed thread rather than relying on findThreadByNameOrThrow().
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25132#pullrequestreview-2834934858

From serb at openjdk.org  Tue May 13 00:13:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:13:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

src/demo/share/jfc/CodePointIM/README.html line 5:

> 3: <head>
> 4:   <title>README - CodePointIM</title>
> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">

I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2085710719

From cjplummer at openjdk.org  Tue May 13 03:17:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 May 2025 03:17:08 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v3]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <ltkonRi6G9JOPkhViFH5GFEdIKB-UoVzwuOIZsCt-Mw=.4c0d9467-a7e5-4bf6-ab4c-e2bdf1f6176c@github.com>

> This is just a preliminary review. I'd like to get some approval for the approach I'm taking. There are over 300 tests that need to be fixed. I've just fixed a handful in this PR to give a feel for the changes I plan on making. If they look ok to you, then I'll update this PR with the needed changes to the rest of the tests.
> 
> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n. There are nearly 1200 nsk/jdi tests. Only about 350 actually need includevirtualthreads=y. I plan making includevirtualthreads=n the default for nsk/jdi tests unless the test does something to override the default and request includevirtualthreads=y.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  No longer any need for -includevirtualthreads with these tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/d59e2ee9..dae40abc

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

  Stats: 17 lines in 16 files changed: 0 ins; 15 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From iveresov at openjdk.org  Tue May 13 03:31:42 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 03:31:42 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v17]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <CWpUVHaMoy5HWRJR_ElKzTXlp7MXN7_wlaNxvbX8lWE=.92253d57-6a2b-4d68-86a0-7105f59e4c22@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/cds/filemap.hpp
  
  Co-authored-by: Dan Heidinga <dan.heidinga at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/d75cb5dc..da4a3420

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Tue May 13 03:34:54 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 03:34:54 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v14]
In-Reply-To: <igPa9ra_wxavTe1aZDK5sZdyb047kXXrhehfefCBOdY=.b916141a-9d05-4f2b-b1f0-850d3d9ab766@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
 <igPa9ra_wxavTe1aZDK5sZdyb047kXXrhehfefCBOdY=.b916141a-9d05-4f2b-b1f0-850d3d9ab766@github.com>
Message-ID: <r2O41bZrC7I71fJykn03yUjAH1xH1QbLUgGXTcg97No=.8ac1aad0-4657-462c-92ad-0d7fa111c8c5@github.com>

On Mon, 12 May 2025 17:13:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/share/cds/filemap.cpp line 1955:
> 
>> 1953:                     " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type,
>> 1954:                     _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries);
>> 1955:       return false;
> 
> The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`.  (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807))
> 
> Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test.

Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085858973

From cjplummer at openjdk.org  Tue May 13 04:01:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 May 2025 04:01:13 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v4]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>

> This is just a preliminary review. I'd like to get some approval for the approach I'm taking. There are over 300 tests that need to be fixed. I've just fixed a handful in this PR to give a feel for the changes I plan on making. If they look ok to you, then I'll update this PR with the needed changes to the rest of the tests.
> 
> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n. There are nearly 1200 nsk/jdi tests. Only about 350 actually need includevirtualthreads=y. I plan making includevirtualthreads=n the default for nsk/jdi tests unless the test does something to override the default and request includevirtualthreads=y.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  update the set of tests that need to be run with -includevirtualthreads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/dae40abc..dcc5c67b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=02-03

  Stats: 25 lines in 22 files changed: 23 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From duke at openjdk.org  Tue May 13 04:06:34 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Tue, 13 May 2025 04:06:34 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Update TestDockerMemoryMetricsSubgroup.java
  
  remove extra space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24930/files
  - new: https://git.openjdk.org/jdk/pull/24930/files/1b131d86..ad855247

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

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

PR: https://git.openjdk.org/jdk/pull/24930

From rvansa at openjdk.org  Tue May 13 06:41:53 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 13 May 2025 06:41:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <3uxxwU4JhY2OG3vQR4o22oYfvlpPLbOO4XXDuA03QJ4=.a9745a21-aae8-48f2-8248-240384067250@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <3uxxwU4JhY2OG3vQR4o22oYfvlpPLbOO4XXDuA03QJ4=.a9745a21-aae8-48f2-8248-240384067250@github.com>
Message-ID: <se-0LKbLGROUh-bekj9iBLbTiQ5rIVKDh569aVB31rQ=.5ce8c637-4248-42bc-a156-a23abb48ecd4@github.com>

On Mon, 12 May 2025 21:33:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fields can have the same name in the JVMS, just not the JVMLS. 

OK, thanks for the explanation. Then I need to update the code to either sort based on both name and signature, or ensure that the index in jump table points to first field with the name same as the (i * 16)th field. I'll probably go the latter path. And I should probably create a test for that...

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2875227843

From iklam at openjdk.org  Tue May 13 07:45:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 07:45:07 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v14]
In-Reply-To: <r2O41bZrC7I71fJykn03yUjAH1xH1QbLUgGXTcg97No=.8ac1aad0-4657-462c-92ad-0d7fa111c8c5@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
 <igPa9ra_wxavTe1aZDK5sZdyb047kXXrhehfefCBOdY=.b916141a-9d05-4f2b-b1f0-850d3d9ab766@github.com>
 <r2O41bZrC7I71fJykn03yUjAH1xH1QbLUgGXTcg97No=.8ac1aad0-4657-462c-92ad-0d7fa111c8c5@github.com>
Message-ID: <eB4NPExX01nuikNV21fBm0_eeclO56S1Ityg-SemmII=.d6966dc6-1611-4a3e-a5f4-083beb762f81@github.com>

On Tue, 13 May 2025 03:32:13 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 1955:
>> 
>>> 1953:                     " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type,
>>> 1954:                     _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries);
>>> 1955:       return false;
>> 
>> The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`.  (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807))
>> 
>> Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test.
>
> Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ?

You can leave the existing code and just fix the new code you added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2086143903

From stefank at openjdk.org  Tue May 13 08:33:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 May 2025 08:33:38 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v2]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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

 - Re-enable tests after merge
 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/ed0c412d..0485cd2f

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

  Stats: 75811 lines in 2330 files changed: 52604 ins; 13809 del; 9398 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

PR: https://git.openjdk.org/jdk/pull/25114

From shade at openjdk.org  Tue May 13 08:53:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 08:53:56 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <84C5B5W01zqy7tLm8rbbx4OpfkjwvTL2drEEOnrB5p4=.58c24a93-b87c-43ba-920e-1d7859a69923@github.com>

On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

All right, looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25170#pullrequestreview-2835846893

From dholmes at openjdk.org  Tue May 13 08:56:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 May 2025 08:56:55 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
Message-ID: <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>

On Fri, 9 May 2025 17:45:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More conversion; clean up; bug fixes

Some drive-by comments, not a full review as I find this all rather confusing because I don't understand why we used "cds" in AOT specific code in the first place. It makes perfect sense to me that AOT specific code logs to "aot".

It makes far less sense to me why you ever introduced logging that required "cds" and "aot" in the first place, so getting rid of that is a good thing.

For code shared between cds and aot it is less clear to me how to proceed. If the intent is that CDS will be no more and everything is AOT, then a transition path is needed for the logging. I guess this is where your macros come in, though I'm a bit unclear as to why it can be controlled by a user-defined command-line flag rather than only by the CDS/AOT selection arguments operating directly on an internal CDS/AOT configuration setting. ???

src/hotspot/share/cds/aotLogging.hpp line 69:

> 67: //
> 68: //     $ java -Xlog:aot -XX:AOTCache=bad.aot ...
> 69: //     [0.020s][info][cds] trying to map bad.jsa

Is it `bad.jsa` or `bad.aot`?

src/hotspot/share/cds/aotLogging.hpp line 77:

> 75: //     - These logs can be selected ONLY with -Xlog:aot. They are always printed with [aot] decoration
> 76: //
> 77: // [2] When using CDS archives, and PrintAOTLogsAsCDSLogs=true

I guess I am missing some basic knowledge about AOT here. If we are using legacy CDS not AOT, then why would there be any AOT log statements ???

src/hotspot/share/cds/aotLogging.hpp line 146:

> 144:       LogTagSetMapping<LogTag::_aot, T1, T2, T3, T4>::tagset().vwrite(level, fmt, args);
> 145:     }
> 146:   }

```suggestion if possible
    LogTag tag =  PrintAOTLogsAsCDSLogs ? LogTag::_cds : LogTag::_aot;
    LogTagSetMapping<tag, T1, T2, T3, T4>::tagset().vwrite(level, fmt, args);
  }

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

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2835783884
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2086245590
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2086248325
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2086253167

From dholmes at openjdk.org  Tue May 13 08:56:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 May 2025 08:56:56 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
 <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
Message-ID: <LwWfnCe9KOOOL7HeiqvzobIXG7doESmcSk-RfSONvYs=.f1e029cb-18d7-429f-ae04-8b8e078de307@github.com>

On Tue, 13 May 2025 08:34:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More conversion; clean up; bug fixes
>
> src/hotspot/share/cds/aotLogging.hpp line 146:
> 
>> 144:       LogTagSetMapping<LogTag::_aot, T1, T2, T3, T4>::tagset().vwrite(level, fmt, args);
>> 145:     }
>> 146:   }
> 
> ```suggestion if possible
>     LogTag tag =  PrintAOTLogsAsCDSLogs ? LogTag::_cds : LogTag::_aot;
>     LogTagSetMapping<tag, T1, T2, T3, T4>::tagset().vwrite(level, fmt, args);
>   }

Given templates, I'm not sure the above is actually possible. And it is pseudo-code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2086290011

From aturbanov at openjdk.org  Tue May 13 11:13:51 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 11:13:51 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <FqadQmDrGQwPeFHpaJWdxllUSSuodToZxPEHW3wCI1A=.c4df34d2-c771-4e3d-8a53-cc3806e88550@github.com>

On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgentTransformer.java line 31:

> 29: 
> 30: // This class is available on the classpath so it can be accessed by JavaAgentApp
> 31: public class JavaAgentTransformer  implements ClassFileTransformer {

Suggestion:

public class JavaAgentTransformer implements ClassFileTransformer {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2086563541

From coleenp at openjdk.org  Tue May 13 11:41:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 May 2025 11:41:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <pjw_BQ3yPMtobDz51NPY9JtamYYhLMmAr9gCuX1hUOk=.8abd27ec-1482-429c-9eb5-c20eb5d9a8d7@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

Also can you include this:

diff --git a/src/hotspot/share/oops/fieldInfo.cpp b/src/hotspot/share/oops/fieldInfo.cpp
index 300b45277ad..7668faf6187 100644
--- a/src/hotspot/share/oops/fieldInfo.cpp
+++ b/src/hotspot/share/oops/fieldInfo.cpp
@@ -37,8 +37,8 @@ void FieldInfo::print(outputStream* os, ConstantPool* cp) {
                 field_flags().as_uint(),
                 initializer_index(),
                 generic_signature_index(),
-                _field_flags.is_injected() ? lookup_symbol(generic_signature_index())->as_utf8() : cp->symbol_at(generic_signature_index())->as_utf8(),
-                contended_group());
+                field_flags().is_generic() ? cp->symbol_at(generic_signature_index())->as_utf8() : "",
+                is_contended() ? contended_group() : 0);
 }
 

which I fixed for printing.

Also, sorting the fields is inlined code in parse_fields.  Can you make it it's own method?  And it seems to sort the fields before the injected fields are added, so how do you find the injected fields?  I think injected fields aren't added to klasses with >16 fields maybe?

I was going to write a test with JVMTI GetFields and > 16 fields because I'm not sure how/if you're fixing the order that the fields are returned by that API.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2876159539

From hgreule at openjdk.org  Tue May 13 13:18:55 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 13 May 2025 13:18:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <pjw_BQ3yPMtobDz51NPY9JtamYYhLMmAr9gCuX1hUOk=.8abd27ec-1482-429c-9eb5-c20eb5d9a8d7@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <pjw_BQ3yPMtobDz51NPY9JtamYYhLMmAr9gCuX1hUOk=.8abd27ec-1482-429c-9eb5-c20eb5d9a8d7@github.com>
Message-ID: <dLdUM2FNQG42rriQHZ0kNLMWL5dZxrZa8A0YaKz5qco=.06f51864-d4f9-4c66-aa05-ba8ffe21469b@github.com>

On Tue, 13 May 2025 11:39:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I was going to write a test with JVMTI GetFields and > 16 fields because I'm not sure how/if you're fixing the order that the fields are returned by that API.

I experimented with that a bit:

class MyClass {
	public static void main(String[] args) {
		System.out.println("reflection:");
		for (var field : MyClass.class.getDeclaredFields()) {
			System.out.println(field.getName());
		}
	}

	Object d;
	int a;
	Object c;
	int b;
	Object x;
	int m;
	Object e;
	int f;
	Object w;
	int z;
	Object g;
	int s;
	Object q;
	int i;
	Object h;
	int o;
	Object v;
	int y;
	Object j;
}




#include <string.h>
#include "jvmti.h"
#include "jni.h"

void ClassPrepare(jvmtiEnv* jvmti_env, JNIEnv* jni_env, jthread thread, jclass klass) {
    char* ptr;
    jvmtiError err = (*jvmti_env)->GetClassSignature(jvmti_env, klass, &ptr, NULL);
    if (err != JNI_OK) {
	    return;
    }
    if (strcmp("LMyClass;", ptr) == 0) {
        printf("%s\n", ptr);
	jfieldID* fields;
	jint field_count;
	err = (*jvmti_env)->GetClassFields(jvmti_env, klass, &field_count, &fields);
	if (err != JNI_OK) {
	    printf("error\n");
	    return;
	}
    printf("JVMTI:\n");
	for (int i = 0; i < field_count; i++) {
	    err = (*jvmti_env)->GetFieldName(jvmti_env, klass, fields[i], &ptr, NULL, NULL);
	    if (err != JNI_OK) {
		printf("error\n");
	    }
	    printf("%s\n", ptr);
	}
    }
}

jint Agent_OnLoad(JavaVM *vm, char *options, void *reserved) {
    jvmtiEnv *environment;
    jvmtiEventCallbacks callbacks;
    jvmtiError error;
    jint result;

    result = (*vm)->GetEnv(vm, (void**)&environment, JVMTI_VERSION_1_2);
    if(result != 0){
        return JNI_ERR;
    }

    (void)memset(&callbacks, 0, sizeof(callbacks));
    callbacks.ClassPrepare = (void*)&ClassPrepare;

    error = (*environment)->SetEventCallbacks(environment, &callbacks, (jint)sizeof(callbacks));
    if(error != JNI_OK){
        return JNI_ERR;
    }

    error = (*environment)->SetEventNotificationMode(environment, JVMTI_ENABLE, JVMTI_EVENT_CLASS_PREPARE, NULL);
    if (error != JNI_OK) {
	    return JNI_ERR;
    }

    printf("Agent is present and registered hooks\n");

    return JNI_OK;
}


With this change, the order of both JVMTI and reflections depends on the field names. If the original order information is still present, I'd assume sorting the array provided by JVMTI is acceptable.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2876483703

From cnorrbin at openjdk.org  Tue May 13 14:20:48 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 13 May 2025 14:20:48 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v3]
In-Reply-To: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
Message-ID: <t5VhAXldDRFdjJwHxcshgVbZJRZPqIOfB6Pb1fPSCSA=.dc93c458-4684-49c3-b936-9b57908b0373@github.com>

> Hi everyone,
> 
> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
> 
> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
> 
> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.

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

 - removed last traces of hrt.ticks
 - Merge branch 'master' into statsampler-removal
 - feedback fixes
 - removed the PerfDataSamplingInterval flag
 - calculate timestamp in jstat instead of sampling
 - StatSampler + sampling code removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24872/files
  - new: https://git.openjdk.org/jdk/pull/24872/files/ed3670eb..fb53bd44

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

  Stats: 73116 lines in 2258 files changed: 50367 ins; 13675 del; 9074 mod
  Patch: https://git.openjdk.org/jdk/pull/24872.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24872/head:pull/24872

PR: https://git.openjdk.org/jdk/pull/24872

From duke at openjdk.org  Tue May 13 14:48:55 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Tue, 13 May 2025 14:48:55 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

The change looks good. There might be some issues with container engine version parsing.

I wrote 2 comments. but cold not post them. They are in "pending" state.
Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

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

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2876826791

From sspitsyn at openjdk.org  Tue May 13 19:47:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 May 2025 19:47:06 GMT
Subject: RFR: 8353496: SuspendResume1.java and SuspendResume2.java timeout
 after JDK-8319447
Message-ID: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>

The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.

Testing:
- Mach5 test runs of the fixed tests

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

Commit messages:
 - SuspendResume1.java and SuspendResume2.java timeout after JDK-8319447

Changes: https://git.openjdk.org/jdk/pull/25194/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353496
  Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25194/head:pull/25194

PR: https://git.openjdk.org/jdk/pull/25194

From sspitsyn at openjdk.org  Tue May 13 20:21:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 May 2025 20:21:53 GMT
Subject: RFR: 8356588: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 3
In-Reply-To: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
References: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
Message-ID: <eTW3476P9Co-tx718fvBoM1tZVBPMKvPOa03z-otePw=.51c72b25-4aa8-44cd-9330-c39d1b0f240b@github.com>

On Thu, 8 May 2025 21:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There were a small number of tests that were missed with [JDK-8356023](https://bugs.openjdk.org/browse/JDK-8356023) (part 2). Most of these tests are ones that were calling vm.allThreads() directly to search for the needed thread rather than relying on findThreadByNameOrThrow().
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25132#pullrequestreview-2838021295

From asmehra at openjdk.org  Tue May 13 20:53:53 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 13 May 2025 20:53:53 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>

On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

src/hotspot/share/prims/jvmtiAgentList.cpp line 79:

> 77:   JvmtiAgent* next = head(list);
> 78: #if INCLUDE_CDS
> 79:   if (_disable_agent_list) {

Instead of intercepting here would it be better if we can clear `JvmtiAgentList::_list` in `CDSConfig::check_aotmode_create()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2087603909

From amenkov at openjdk.org  Tue May 13 20:54:07 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 13 May 2025 20:54:07 GMT
Subject: RFR: 8356177: Regression after JDK-8352180
Message-ID: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>

The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.

Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/25219/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356177
  Stats: 82 lines in 2 files changed: 78 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25219/head:pull/25219

PR: https://git.openjdk.org/jdk/pull/25219

From iklam at openjdk.org  Tue May 13 21:02:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 21:02:51 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>
Message-ID: <-HkCpXlfsip8P6WTmrVqjb6ZhD10RrhGdKUqf1VETIk=.26ce21f4-47f2-493c-98e7-d1dfdfbab638@github.com>

On Tue, 13 May 2025 20:45:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Instead of intercepting here would it be better if we can clear `JvmtiAgentList::_list` in `CDSConfig::check_aotmode_create()`?

That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.

Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.

I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2087626021

From amenkov at openjdk.org  Tue May 13 22:15:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 13 May 2025 22:15:03 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4
In-Reply-To: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
Message-ID: <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>

On Mon, 12 May 2025 19:35:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
> 
> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
> 
> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod009.java line 120:

> 118:         thrRef = debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 119:         if (thrRef == null) {
> 120:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

The message mentions old `threadByName`

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod010.java line 119:

> 117:         thrRef = debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 118:         if (thrRef == null) {
> 119:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod014.java line 123:

> 121:             debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 122:         if (thrRef == null) {
> 123:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance009.java line 104:

> 102:         ThreadReference thrRef = debuggee.threadByFieldName(rType, "thread", DEBUGGEE_THRNAME);
> 103:         if (thrRef == null) {
> 104:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod003.java line 148:

> 146:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 147:         if (thrRef == null) {
> 148:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod004.java line 118:

> 116:         thrRef = debuggee.threadByFieldName(debuggeeClass, "testThread", DEBUGGEE_THRNAME);
> 117:         if (thrRef == null) {
> 118:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod005.java line 122:

> 120:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 121:         if (thrRef == null) {
> 122:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod006.java line 120:

> 118:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 119:         if (thrRef == null) {
> 120:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod007.java line 136:

> 134:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 135:         if (thrRef == null) {
> 136:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod008.java line 131:

> 129:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 130:         if (thrRef == null) {
> 131:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod009.java line 131:

> 129:         thrRef = debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 130:         if (thrRef == null) {
> 131:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod014.java line 155:

> 153:             debuggee.threadByFieldName(rType[0], "testThread", DEBUGGEE_THRNAME);
> 154:         if (thrRef == null) {
> 155:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue002.java line 116:

> 114:         thrRef = debuggee.threadByFieldName(debuggeeClass, "testThread", DEBUGGEE_THRNAME);
> 115:         if (thrRef == null) {
> 116:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee's thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue003.java line 149:

> 147:         thrRef = debuggee.threadByFieldName(debuggeeClass, "testThread", DEBUGGEE_THRNAME);
> 148:         if (thrRef == null) {
> 149:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee's thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004.java line 129:

> 127:         thrRef = debuggee.threadByFieldName(debuggeeClass, "testThread", DEBUGGEE_THRNAME);
> 128:         if (thrRef == null) {
> 129:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee's thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue005.java line 116:

> 114:         thrRef = debuggee.threadByFieldName(debuggeeClass, "testThread", DEBUGGEE_THRNAME);
> 115:         if (thrRef == null) {
> 116:             log.complain("TEST FAILURE: Method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename004.java line 145:

> 143:                 debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 144:             if (thrRef == null) {
> 145:                 throw new Failure("method Debugee.threadByName() returned null for debuggee thread "

Need to update error message or use threadByFieldNameOrThrow and drop this check

test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourcenames002.java line 145:

> 143:                 debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 144:             if (thrRef == null) {
> 145:                 throw new Failure("method Debugee.threadByName() returned null for debuggee thread "

Need to update error message or use threadByFieldNameOrThrow and drop this check

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue003.java line 115:

> 113:         ThreadReference auxThread =
> 114:             debuggee.threadByFieldNameOrThrow(rType, "auxThr",
> 115:                                               DEBUGGEE_AUX_THREAD_NAME);

I suppose this should to moved inside try block so `quitDebuggee` is called on error

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues003.java line 121:

> 119:         ThreadReference auxThread =
> 120:             debuggee.threadByFieldNameOrThrow(rType, "auxThr",
> 121:                                               DEBUGGEE_AUX_THREAD_NAME);

Need to move inside `try` block

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue005/setvalue005.java line 165:

> 163:             debuggee.threadByFieldName(rType, "mainThread", DEBUGGEE_THRDNAME);
> 164:         if (thrRef == null) {
> 165:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message
BTW `debuggee.classByName` also can throw exceptions, need to catch and call `quitDebuggee()` (this applicable to other changes in the fix when `debuggee.classByName` is called outside of try block)

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue006/setvalue006.java line 181:

> 179: 
> 180:         // debuggee main class
> 181:         ReferenceType rType = debuggee.classByName(DEBUGGEE_CLASS);

can throw an exception

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue006/setvalue006.java line 186:

> 184:             debuggee.threadByFieldName(rType, "mainThread", DEBUGGEE_THRDNAME);
> 185:         if (thrRef == null) {
> 186:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java line 208:

> 206: 
> 207:     private void executeCase(int testCase, String threadName2) {
> 208:         ReferenceType debuggeeClass = debuggee.classByName(debuggeeName);

need to catch exceptions and call `debuggee.quit()`

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002.java line 95:

> 93: 
> 94:         // debuggee main class
> 95:         ReferenceType rType = debuggee.classByName(DEBUGGEE_CLASS);

catch exception and call `quitDebuggee()`

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002.java line 100:

> 98:             debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 99:         if (thrRef == null) {
> 100:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update the message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes006.java line 110:

> 108: 
> 109:         // debuggee main class
> 110:         ReferenceType rType = debuggee.classByName(DEBUGGEE_CLASS);

Need to catch exceptions

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes006.java line 115:

> 113:             debuggee.threadByFieldName(rType, "testThread", DEBUGGEE_THRNAME);
> 114:         if (thrRef == null) {
> 115:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

Need to update error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007.java line 110:

> 108: 
> 109:         // debuggee main class
> 110:         ReferenceType rType = debuggee.classByName(DEBUGGEE_CLASS);

Also can throw an exception

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007.java line 115:

> 113:             debuggee.threadByFieldName(rType, "mainThread", DEBUGGEE_MAIN_THREAD_NAME);
> 114:         if (mainThread == null) {
> 115:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007.java line 124:

> 122:             debuggee.threadByFieldName(rType, "auxThr", DEBUGGEE_AUX_THREAD_NAME);
> 123:         if (auxThread == null) {
> 124:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "

error message

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 119:

> 117: 
> 118:         // debuggee main class
> 119:         mainClass = debuggee.classByName(DEBUGGEE_CLASS);

Maybe just move this into `try` and replace `debuggee.threadByFieldName` with `debuggee.threadByFieldNameOrThrow`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087642353
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087645280
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087646349
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087648971
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087656414
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087657140
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087657694
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087658347
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087659210
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087659847
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087662171
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087663522
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087664932
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087677879
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087678551
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087678872
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087683417
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087684378
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087686629
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087688875
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087689600
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087694192
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087693950
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087697256
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087698746
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087698970
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087701217
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087701506
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087702115
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087702349
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087702545
PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087705024

From amenkov at openjdk.org  Tue May 13 22:21:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 13 May 2025 22:21:57 GMT
Subject: RFR: 8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java
 fails sometimes on macOS
In-Reply-To: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
References: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
Message-ID: <ohqoncI5ggb6qS0aAfrkZPmC-uKr_gqZw3PWPF7qBF8=.c914e4fa-8651-4b50-96b6-1ab0efda85c1@github.com>

On Fri, 9 May 2025 20:59:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.
> 
> Tested by running test on all supported platforms.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25156#pullrequestreview-2838254822

From iveresov at openjdk.org  Tue May 13 22:37:55 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 22:37:55 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v18]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <ePe5BjIl09D18AT02ekkXuDuxcBfot22-jAbgyfyL64=.117f471f-654f-4996-8551-bdbdab7edc6f@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with 34 additional commits since the last revision:

 - Address Ioi's comments
 - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
   
   Reviewed-by: vlivanov, kvn
 - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
   
   Reviewed-by: naoto
 - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
   
   Reviewed-by: wkemper
 - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default
   
   Reviewed-by: asemenyuk
 - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
   
   Reviewed-by: naoto, bpb
 - 8356447: Change default for EagerJVMCI to true
   
   Reviewed-by: yzheng, kvn, never
 - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component
   
   Reviewed-by: alanb
 - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
   
   Reviewed-by: mcimadamore
 - 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath
   
   Reviewed-by: darcy
 - ... and 24 more: https://git.openjdk.org/jdk/compare/da4a3420...72030a30

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/da4a3420..72030a30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16-17

  Stats: 7451 lines in 145 files changed: 4269 ins; 1931 del; 1251 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From cjplummer at openjdk.org  Tue May 13 22:39:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 May 2025 22:39:52 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4
In-Reply-To: <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
Message-ID: <8mn28z_GYTH9IwYstb1uIAMW9OvQXtb3_FRzsWyYYCU=.0b647309-12ea-4b92-b659-1c04d10feb92@github.com>

On Tue, 13 May 2025 21:55:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
>> 
>> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
>> 
>> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue005/setvalue005.java line 165:
> 
>> 163:             debuggee.threadByFieldName(rType, "mainThread", DEBUGGEE_THRDNAME);
>> 164:         if (thrRef == null) {
>> 165:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "
> 
> Need to update error message
> BTW `debuggee.classByName` also can throw exceptions, need to catch and call `quitDebuggee()` (this applicable to other changes in the fix when `debuggee.classByName` is called outside of try block)

This is a common pattern in my changes. I'l need to add something like the following catch:


        } catch (Exception e) {
            e.printStackTrace();
            log.complain("TEST FAILURE: caught unexpected exception: " + e);
            tot_res = Consts.TEST_FAILED;
        }


It would have been a lot cleaner if these tests were all written to just let the exception happen and not worry about printing messages about what it was doing when the exception was thrown. The exception stack trace provides all the info you need.

The error handling in these tests is frustrating to work with. It's inconsistent and incomplete. Many catch exceptions, print a failure message (and no exception backtrace), and them resume at the next step, only to hang as a result.

I was tempted to get rid of a lot of the failure handling when thrRef == null and just use threadByFieldNameOrThrow() instead of threadByFieldName(), but also wanted to limit the scope of the changes. I did observe that in general this works well. While making the changes for this PR I dealt with a lot of failures due to calling threadByFieldNameOrThrow() with bad args, and the test always failed quickly and gracefully. But in the end I changed to threadByFieldName() to keep things a bit more consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2087727193

From iveresov at openjdk.org  Tue May 13 22:40:42 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 22:40:42 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v19]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <IBHtyU9WVlYVeXY5k8SkGMgq0_2tXDTpKxD7t1r-6GI=.e144313a-2c08-4c40-aa38-aadeae1a28b1@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:

 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
   
   Reviewed-by: vlivanov, kvn
 - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
   
   Reviewed-by: naoto
 - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
   
   Reviewed-by: wkemper
 - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default
   
   Reviewed-by: asemenyuk
 - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
   
   Reviewed-by: naoto, bpb
 - 8356447: Change default for EagerJVMCI to true
   
   Reviewed-by: yzheng, kvn, never
 - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component
   
   Reviewed-by: alanb
 - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
   
   Reviewed-by: mcimadamore
 - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18
  Stats: 3330 lines in 59 files changed: 3116 ins; 100 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Tue May 13 22:44:55 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 22:44:55 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v14]
In-Reply-To: <eB4NPExX01nuikNV21fBm0_eeclO56S1Ityg-SemmII=.d6966dc6-1611-4a3e-a5f4-083beb762f81@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <ALI0AEPMP3USydg752jFJL_gKrYULXuaT9dNMzjZfJA=.f4ceee8b-b53c-44d0-80a3-82016b69f242@github.com>
 <igPa9ra_wxavTe1aZDK5sZdyb047kXXrhehfefCBOdY=.b916141a-9d05-4f2b-b1f0-850d3d9ab766@github.com>
 <r2O41bZrC7I71fJykn03yUjAH1xH1QbLUgGXTcg97No=.8ac1aad0-4657-462c-92ad-0d7fa111c8c5@github.com>
 <eB4NPExX01nuikNV21fBm0_eeclO56S1Ityg-SemmII=.d6966dc6-1611-4a3e-a5f4-083beb762f81@github.com>
Message-ID: <KaxA5cOMGw3nFUmo9NT3u1cWZwsX5-3BeCUOelMOLuA=.760bd40a-7d6c-47fd-ba94-58f137609416@github.com>

On Tue, 13 May 2025 07:42:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ?
>
> You can leave the existing code and just fix the new code you added.

Done. And changed the test. Please take a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087730827

From iklam at openjdk.org  Tue May 13 23:15:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 23:15:57 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v19]
In-Reply-To: <IBHtyU9WVlYVeXY5k8SkGMgq0_2tXDTpKxD7t1r-6GI=.e144313a-2c08-4c40-aa38-aadeae1a28b1@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <IBHtyU9WVlYVeXY5k8SkGMgq0_2tXDTpKxD7t1r-6GI=.e144313a-2c08-4c40-aa38-aadeae1a28b1@github.com>
Message-ID: <soHAN6appRYQES0UwMhACNvFycZntHr_4lviv2ExMko=.a08cfe93-976b-4ffa-afef-dfeed61bfd9d@github.com>

On Tue, 13 May 2025 22:40:42 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:
> 
>  - Merge branch 'master' into pp2
>  - Address Ioi's comments
>  - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
>    
>    Reviewed-by: vlivanov, kvn
>  - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
>    
>    Reviewed-by: naoto
>  - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
>    
>    Reviewed-by: wkemper
>  - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default
>    
>    Reviewed-by: asemenyuk
>  - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
>    
>    Reviewed-by: naoto, bpb
>  - 8356447: Change default for EagerJVMCI to true
>    
>    Reviewed-by: yzheng, kvn, never
>  - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component
>    
>    Reviewed-by: alanb
>  - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
>    
>    Reviewed-by: mcimadamore
>  - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900

test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115:

> 113: 
> 114:         out = CDSTestUtils.executeAndLog(pb, "production_failure");
> 115:         out.shouldContain("does not equal");

Since all the flags have `Profile` in them, I think we should use this to match the intended output:


String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting";
out.shouldNotMatch(errorPattern);
...
out.shouldMatch(errorPattern);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087753972

From iveresov at openjdk.org  Tue May 13 23:15:57 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 23:15:57 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v19]
In-Reply-To: <soHAN6appRYQES0UwMhACNvFycZntHr_4lviv2ExMko=.a08cfe93-976b-4ffa-afef-dfeed61bfd9d@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <IBHtyU9WVlYVeXY5k8SkGMgq0_2tXDTpKxD7t1r-6GI=.e144313a-2c08-4c40-aa38-aadeae1a28b1@github.com>
 <soHAN6appRYQES0UwMhACNvFycZntHr_4lviv2ExMko=.a08cfe93-976b-4ffa-afef-dfeed61bfd9d@github.com>
Message-ID: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com>

On Tue, 13 May 2025 23:10:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:
>> 
>>  - Merge branch 'master' into pp2
>>  - Address Ioi's comments
>>  - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
>>    
>>    Reviewed-by: vlivanov, kvn
>>  - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
>>    
>>    Reviewed-by: naoto
>>  - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
>>    
>>    Reviewed-by: wkemper
>>  - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default
>>    
>>    Reviewed-by: asemenyuk
>>  - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
>>    
>>    Reviewed-by: naoto, bpb
>>  - 8356447: Change default for EagerJVMCI to true
>>    
>>    Reviewed-by: yzheng, kvn, never
>>  - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component
>>    
>>    Reviewed-by: alanb
>>  - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
>>    
>>    Reviewed-by: mcimadamore
>>  - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900
>
> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115:
> 
>> 113: 
>> 114:         out = CDSTestUtils.executeAndLog(pb, "production_failure");
>> 115:         out.shouldContain("does not equal");
> 
> Since all the flags have `Profile` in them, I think we should use this to match the intended output:
> 
> 
> String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting";
> out.shouldNotMatch(errorPattern);
> ...
> out.shouldMatch(errorPattern);

`SpecTrapLimitExtraEntries` does not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087755889

From iveresov at openjdk.org  Tue May 13 23:46:42 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 23:46:42 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v20]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <xCJ9B29FEKp_ChUpk8yVrwexnGdOimjwKiRxacxi5aI=.f824e123-5838-4d1b-b2d0-7ec8a2a40af9@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Address Ioi's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/1669f900..fd26cfe4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18-19

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

PR: https://git.openjdk.org/jdk/pull/24886

From iklam at openjdk.org  Tue May 13 23:46:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 23:46:42 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v20]
In-Reply-To: <xCJ9B29FEKp_ChUpk8yVrwexnGdOimjwKiRxacxi5aI=.f824e123-5838-4d1b-b2d0-7ec8a2a40af9@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <xCJ9B29FEKp_ChUpk8yVrwexnGdOimjwKiRxacxi5aI=.f824e123-5838-4d1b-b2d0-7ec8a2a40af9@github.com>
Message-ID: <GbQqnoDPcVkusZ33LEHm2u7jxIWykYRFYU71sMwXeKk=.70abb911-b911-4844-94ce-d75cdb654804@github.com>

On Tue, 13 May 2025 23:43:01 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Ioi's comments

updates are good!

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2838347038

From iveresov at openjdk.org  Tue May 13 23:46:42 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 13 May 2025 23:46:42 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v19]
In-Reply-To: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <IBHtyU9WVlYVeXY5k8SkGMgq0_2tXDTpKxD7t1r-6GI=.e144313a-2c08-4c40-aa38-aadeae1a28b1@github.com>
 <soHAN6appRYQES0UwMhACNvFycZntHr_4lviv2ExMko=.a08cfe93-976b-4ffa-afef-dfeed61bfd9d@github.com>
 <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com>
Message-ID: <f0pKsIF7IPeUDw-PhROEAIwMJNqe82ktngBm3PZwpRY=.a9d09260-e4cb-4d42-b611-b51454fe737d@github.com>

On Tue, 13 May 2025 23:13:42 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115:
>> 
>>> 113: 
>>> 114:         out = CDSTestUtils.executeAndLog(pb, "production_failure");
>>> 115:         out.shouldContain("does not equal");
>> 
>> Since all the flags have `Profile` in them, I think we should use this to match the intended output:
>> 
>> 
>> String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting";
>> out.shouldNotMatch(errorPattern);
>> ...
>> out.shouldMatch(errorPattern);
>
> `SpecTrapLimitExtraEntries` does not.

Fixed. Take a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087775255

From dholmes at openjdk.org  Wed May 14 00:54:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 May 2025 00:54:59 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v2]
In-Reply-To: <tEr9ltXTwUS_VpGxa28ZQDAssyhL22tneOlg4aAGiuM=.76079982-0aed-4c25-ba32-18257e3f39c7@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <tEr9ltXTwUS_VpGxa28ZQDAssyhL22tneOlg4aAGiuM=.76079982-0aed-4c25-ba32-18257e3f39c7@github.com>
Message-ID: <zmgI-UNO6ooBIzPcJdBToJYe9eMzeIVyK8_l3FuBvAA=.1cd862de-9435-4150-895d-5401eba1430d@github.com>

On Tue, 13 May 2025 16:14:06 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propose we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap in the periodic printing before/after GC invocation(s). The periodic printing is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HeapInfoTest should check that GC.heap_info actually runs

@jsikstro I think this is relevant to the serviceability folk. Also you are making a number of changes to the way tool commands behave so this definitely needs a CSR request, and also a Release Note.

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2878290615

From iklam at openjdk.org  Wed May 14 01:07:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 01:07:36 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Removed PrintAOTLogsAsCDSLogs and improved comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/e2156fbe..dddf591d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=02-03

  Stats: 64 lines in 3 files changed: 26 ins; 22 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From iklam at openjdk.org  Wed May 14 01:07:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 01:07:37 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
 <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
Message-ID: <W49ZmGwD28rn00aTVivXS7tyAQnwJdbVqjpr_kh0LCQ=.2468267a-a937-4eaa-a8f8-5772ae226fa3@github.com>

On Tue, 13 May 2025 08:30:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More conversion; clean up; bug fixes
>
> src/hotspot/share/cds/aotLogging.hpp line 69:
> 
>> 67: //
>> 68: //     $ java -Xlog:aot -XX:AOTCache=bad.aot ...
>> 69: //     [0.020s][info][cds] trying to map bad.jsa
> 
> Is it `bad.jsa` or `bad.aot`?

It should be `bad.aot`. I fixed the comment (there were a few other typos).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087857530

From iklam at openjdk.org  Wed May 14 01:07:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 01:07:37 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <LwWfnCe9KOOOL7HeiqvzobIXG7doESmcSk-RfSONvYs=.f1e029cb-18d7-429f-ae04-8b8e078de307@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
 <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
 <LwWfnCe9KOOOL7HeiqvzobIXG7doESmcSk-RfSONvYs=.f1e029cb-18d7-429f-ae04-8b8e078de307@github.com>
Message-ID: <_pG8Muq92CHmSIQdVZIbYcZVp0KD7NoA6-pXVPfcyqE=.343710ce-1e55-47a7-ab38-cc450e898db3@github.com>

On Tue, 13 May 2025 08:53:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Given templates, I'm not sure the above is actually possible. And it is pseudo-code.

I tried it and it didn't want. The template wants a constant expression for parameter substitution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087857124

From iklam at openjdk.org  Wed May 14 01:10:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 01:10:52 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
 <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
Message-ID: <RNMTROK9aANTtZyx4hQF9JPbQECZpMzUp_pNHXTNk1Y=.e6710f23-ec66-4132-9e25-0292e2ca14fd@github.com>

On Tue, 13 May 2025 08:32:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More conversion; clean up; bug fixes
>
> src/hotspot/share/cds/aotLogging.hpp line 77:
> 
>> 75: //     - These logs can be selected ONLY with -Xlog:aot. They are always printed with [aot] decoration
>> 76: //
>> 77: // [2] When using CDS archives, and PrintAOTLogsAsCDSLogs=true
> 
> I guess I am missing some basic knowledge about AOT here. If we are using legacy CDS not AOT, then why would there be any AOT log statements ???

I got rid of the `PrintAOTLogsAsCDSLogs` option. I thought maybe it could make the transition easier for some users but it's probably an overkill.

I've updated aotLogging.hpp to describe the deprecation process. I tried to model it after the deprecation process for VM options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087860290

From iklam at openjdk.org  Wed May 14 01:31:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 01:31:51 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v3]
In-Reply-To: <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <rsvwtEoiddLcAfI63XAd32Te_0Mpv9-OBhzK6Upz9rs=.1cc5de9b-99bc-488c-a97f-1a67bae3c5fa@github.com>
 <1UV936Jx3HNb6Tt-BzzLFcHvfaZ2ZJ-6pGsKTacsgD8=.be5119c4-93a0-4844-9ed8-4d92b369ef19@github.com>
Message-ID: <huRriCewulEhebdzO9oyKNxPSLBmtqAEGr463EbCaZ0=.214b683b-ab3c-49e9-a9e1-3a54e2da7097@github.com>

On Tue, 13 May 2025 08:52:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Some drive-by comments, not a full review as I find this all rather confusing because I don't understand why we used "cds" in AOT specific code in the first place. It makes perfect sense to me that AOT specific code logs to "aot".
> 
> It makes far less sense to me why you ever introduced logging that required "cds" and "aot" in the first place, so getting rid of that is a good thing.
> 
> For code shared between cds and aot it is less clear to me how to proceed. If the intent is that CDS will be no more and everything is AOT, then a transition path is needed for the logging. I guess this is where your macros come in, though I'm a bit unclear as to why it can be controlled by a user-defined command-line flag rather than only by the CDS/AOT selection arguments operating directly on an internal CDS/AOT configuration setting. ???

Since [JEP 483](https://openjdk.org/jeps/483), all ahead-of-time optimizations in HotSpot fall under the "AOT" umbrella. We have several JEPs for new optimizations that use the AOT terminology. E.g., [JEP 515 - Ahead-of-Time Method Profiling](https://openjdk.org/jeps/515).

The traditional CDS functionality is part of (a strict subset of) AOT -- ahead-of-time processing of class metadata. Classical CDS VM flags such as `-Xshare` can be seen as special interfaces to a subset of the AOT functionality. We are providing these flags for backwards compatibility, as there are equivalent ways to access the same features (and more) with the new `-XX:AOTXXX` flags introduced in JEP 483. Eventually, I think we will deprecate and remove the classical CDS flags.

Given this background, moving `-Xlog:cds` to `-Xlog:aot` is part of the transition plan. These logs will probably be the first legacy CDS interfaces to be removed from the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/25136#issuecomment-2878368790

From fyang at openjdk.org  Wed May 14 01:59:57 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 May 2025 01:59:57 GMT
Subject: RFR: 8353496: SuspendResume1.java and SuspendResume2.java timeout
 after JDK-8319447
In-Reply-To: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
References: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
Message-ID: <3ppyBHzkmtVo9bNhDvPdQbbFqkLrjw8E19BeklKmaGU=.76fbc978-7136-4c20-82f1-ae50bd430aa3@github.com>

On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
> The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.
> 
> Testing:
> - Mach5 test runs of the fixed tests

FYI: The same tests are passing after this change on both my linux-aarch64 and linux-riscv64 platforms. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25194#issuecomment-2878399012

From asmehra at openjdk.org  Wed May 14 02:23:51 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 May 2025 02:23:51 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <-HkCpXlfsip8P6WTmrVqjb6ZhD10RrhGdKUqf1VETIk=.26ce21f4-47f2-493c-98e7-d1dfdfbab638@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>
 <-HkCpXlfsip8P6WTmrVqjb6ZhD10RrhGdKUqf1VETIk=.26ce21f4-47f2-493c-98e7-d1dfdfbab638@github.com>
Message-ID: <kqhCPc0be_lUwxRPycPf41J5Dw2ZT_V9p-hW5e78RV0=.fe150ef3-decd-4604-a4f5-ace3710a8c8c@github.com>

On Tue, 13 May 2025 20:59:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
> 
> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
> 

It looks like the memory for these entries is never freed even after unloading the agents during shutdown. So there memory is never reclaimed. And setting `JvmtiAgentList::_list` to nullptr is not really changing that behavior. 

> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.

hmmm...not sure about that. Ideally we should ignore the jvmti options that add agents if the JVM is in assembly phase. But we detect the assembly phase after jvmti options have been processed.
IMO clearing the _list is the next best approach. If that doesn't work then more intrusive fix like intercepting the `JvmtiAgentList::Iterator`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2087914075

From cjplummer at openjdk.org  Wed May 14 03:32:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 03:32:50 GMT
Subject: RFR: 8353496: SuspendResume1.java and SuspendResume2.java timeout
 after JDK-8319447
In-Reply-To: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
References: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
Message-ID: <zhzyaL_F3I9diBX45rxuZYeAT5N_WiOs9pQBqs_ODmw=.73d15b77-9666-4879-a6d3-9df2fa2c7a90@github.com>

On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
> The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.
> 
> Testing:
> - Mach5 test runs of the fixed tests

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25194#pullrequestreview-2838614934

From dholmes at openjdk.org  Wed May 14 03:37:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 May 2025 03:37:52 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
Message-ID: <V4Q5u_CqX-M-dHyQwefd-2lGFt_-QYR1SWWXZg9rbrI=.ce2e253e-a57c-4851-849a-2960b38a7811@github.com>

On Wed, 14 May 2025 01:07:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed PrintAOTLogsAsCDSLogs and improved comments

src/hotspot/share/cds/aotLogging.hpp line 87:

> 85: // ===================
> 86: //
> 87: // This is model after the deprecate/obsolete/removal process of VM options in arguments.cpp

Suggestion:

// This is modeled after the deprecate/obsolete/expire process of VM options in arguments.cpp

src/hotspot/share/cds/aotLogging.hpp line 92:

> 90: //          the CDS Compatibility Logs must be selected with -Xlog:cds
> 91: //
> 92: // JDK 26 - Same as above, except that when -Xlog:cds is specified in the command-line, an warning

Suggestion:

// JDK 26 - Same as above, except that when -Xlog:cds is specified in the command-line, a warning

src/hotspot/share/cds/aotLogging.hpp line 98:

> 96: //          the CDS Compatibility Logs must be selected with -Xlog:aot.
> 97: //
> 98: //          When -Xlog:cds is specified in the command-line, an warning message is printed to

Suggestion:

//          When -Xlog:cds is specified in the command-line, a warning message is printed to

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087966346
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087966639
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087966847

From dholmes at openjdk.org  Wed May 14 03:57:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 May 2025 03:57:52 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
Message-ID: <sY8shShCouTchqSxnDZ2wXfaNLanZHGrAZUAU8wo1SE=.c17f6346-7165-4c14-b75a-a455d2aafd18@github.com>

On Wed, 14 May 2025 01:07:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed PrintAOTLogsAsCDSLogs and improved comments

Thanks for getting rid of the flag and for explaining the longer term plans. This is all making a lot more sense to me now.

But given you state that CDS is a subset of AOT - the AOT for metaspace - does it really make sense to simply rebadge "cds" logging as "aot"? It seems to me that "aot" logging will generate massive amounts of data if everything AOT related logs when "aot" is used. Would you not want finer-grained logging such that "cds" becomes "aot+metaspace" as described?

I'm undecided whether this aspect of the work requires a CSR request ... but it never hurts to have one. Obviously in 26 there will be one for the actual deprecation/obsoletion/expiration process.

src/hotspot/share/cds/aotLogging.hpp line 63:

> 61: // The messages printed with the log_aot_xxx() macros work as if they are
> 62: // using the [cds] tag when running with the "classic" CDS flags such as
> 63: // -XX:SharedArchiveFile:

What if you specify no flags and rely on the implicit settings e.g. `-Xshare:auto`, will `-Xlog:cds` continue to work as today?

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

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2838631912
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2087973430

From alanb at openjdk.org  Wed May 14 05:49:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 05:49:50 GMT
Subject: RFR: 8353496: SuspendResume1.java and SuspendResume2.java timeout
 after JDK-8319447
In-Reply-To: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
References: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
Message-ID: <fFl7Ck1xBeCNbPkHl64UIXJirev4WZ6FqTI9zfqjsSs=.ab831d58-2a38-4e1a-80b4-dd7b399dc4ba@github.com>

On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
> The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.
> 
> Testing:
> - Mach5 test runs of the fixed tests

Marked as reviewed by alanb (Reviewer).

I see Fei Yang's comment confirming that this fixes the timeouts in their environment, that is useful to know.

Main lesson here is that the virtual thread is not fair. A virtual thread doing short sleep, sleep(1) in one case here, may be continued and execute before other virtual threads that are queued to continue.

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

PR Review: https://git.openjdk.org/jdk/pull/25194#pullrequestreview-2838801041
PR Comment: https://git.openjdk.org/jdk/pull/25194#issuecomment-2878748617

From ihse at openjdk.org  Wed May 14 06:35:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:56 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
Message-ID: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>

On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>> 
>> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
>> 
>> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.
>
> src/demo/share/jfc/CodePointIM/README.html line 5:
> 
>> 3: <head>
>> 4:   <title>README - CodePointIM</title>
>> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">
> 
> I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088152886

From ihse at openjdk.org  Wed May 14 06:35:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:57 GMT
Subject: Integrated: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <1uf8Qu09x2byR-S1kMvt4zMdBu_BKZHCvx13v-uaxYc=.9e974fe5-0125-4001-99f6-acbba3ea517d@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

This pull request has now been integrated.

Changeset: dd251599
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd2515993bf76f424e4c56d529ae1541f55e3f8b
Stats:     794 lines in 53 files changed: 2 ins; 9 del; 783 mod

8356644: Update encoding declaration to UTF-8

Reviewed-by: prr, naoto

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

PR: https://git.openjdk.org/jdk/pull/25148

From jsjolen at openjdk.org  Wed May 14 06:38:12 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 14 May 2025 06:38:12 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
Message-ID: <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>

On Wed, 14 May 2025 01:07:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed PrintAOTLogsAsCDSLogs and improved comments

Hi,

Just one comment. I'm approving, the UL code looks good to me.

src/hotspot/share/cds/aotLogging.hpp line 82:

> 80: //
> 81: // [2] When using CDS archives
> 82: //     - These logs can be selected ONLY with -Xlog:cds. They are always printed with [cds] decoration

OK, so if I use `-Xlog:all`, what will they be selected as?

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2838902352
PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2088151655

From jsikstro at openjdk.org  Wed May 14 06:47:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 14 May 2025 06:47:52 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v2]
In-Reply-To: <zmgI-UNO6ooBIzPcJdBToJYe9eMzeIVyK8_l3FuBvAA=.1cd862de-9435-4150-895d-5401eba1430d@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <tEr9ltXTwUS_VpGxa28ZQDAssyhL22tneOlg4aAGiuM=.76079982-0aed-4c25-ba32-18257e3f39c7@github.com>
 <zmgI-UNO6ooBIzPcJdBToJYe9eMzeIVyK8_l3FuBvAA=.1cd862de-9435-4150-895d-5401eba1430d@github.com>
Message-ID: <TLqH-pYzx-K0l6BbKpbNukQl2wUdXdGo8zOIrDwA7xs=.8cfeff86-7c59-4a4b-a906-9257a2c6d3a4@github.com>

On Wed, 14 May 2025 00:51:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   HeapInfoTest should check that GC.heap_info actually runs
>
> @jsikstro I think this is relevant to the serviceability folk. Also you are making a number of changes to the way tool commands behave so this definitely needs a CSR request, and also a Release Note.

@dholmes-ora Thank you for the input! I will take a look at creating a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2878876071

From serb at openjdk.org  Wed May 14 06:52:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 06:52:55 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
 <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
Message-ID: <IpJv8SIJ2TSeGf31v4EPP7vbfL9injugtQRKbLZy1MM=.3980df30-43fb-48a2-a48b-4cafcf7352fd@github.com>

On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

FIled: https://bugs.openjdk.org/browse/JDK-8356937

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088181402

From iklam at openjdk.org  Wed May 14 07:20:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 07:20:52 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
 <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>
Message-ID: <JwsoeT5ad8ix3XdQGF2DSnS72xeQolX_i8EjinYECvc=.2bc76eb3-3f59-4655-a073-0d20456cadc2@github.com>

On Wed, 14 May 2025 06:31:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed PrintAOTLogsAsCDSLogs and improved comments
>
> src/hotspot/share/cds/aotLogging.hpp line 82:
> 
>> 80: //
>> 81: // [2] When using CDS archives
>> 82: //     - These logs can be selected ONLY with -Xlog:cds. They are always printed with [cds] decoration
> 
> OK, so if I use `-Xlog:all`, what will they be selected as?

`-Xlog:all` will enable all `LogTagSets`. Each `aot_log_xxx()` statement will print exactly one log. When using AOT caches, the log will be printed with `[aot]` decorations. When using CDS archives, the log will be printed with `[cds]` decorations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2088234239

From sspitsyn at openjdk.org  Wed May 14 08:10:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:10:52 GMT
Subject: RFR: 8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java
 fails sometimes on macOS
In-Reply-To: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
References: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
Message-ID: <5a1MVlK6fw1rWfL2sjxBfvEEDEHUquQtPJKS1VNOmO8=.6c7e1bcc-9649-4e56-a266-e08ba00eace0@github.com>

On Fri, 9 May 2025 20:59:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.
> 
> Tested by running test on all supported platforms.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25156#pullrequestreview-2839193814

From sspitsyn at openjdk.org  Wed May 14 08:13:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:13:54 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v4]
In-Reply-To: <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
Message-ID: <r8HMXHNzzh1LxOD7fRugHukQa4pMvqu2dgl9H1XdQsQ=.ebc64827-8390-4979-b312-4bc896cf9e38@github.com>

On Tue, 13 May 2025 04:01:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the set of tests that need to be run with -includevirtualthreads

test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq002.java line 251:

> 249:         String lineForComm  = "lineForComm";
> 250: 
> 251:         //ThreadReference   mainThread = debuggee.threadByNameOrThrow("main");

Q: Do you want to keep this commented out line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2087600650

From sspitsyn at openjdk.org  Wed May 14 08:16:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:16:56 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v4]
In-Reply-To: <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
Message-ID: <dt2Xeu4AgSfp3dMgY_dpTZVD6RNc85ezAKyVp_VZeHI=.e80a3cd3-0955-4501-a1c3-b407177d4779@github.com>

On Tue, 13 May 2025 04:01:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the set of tests that need to be run with -includevirtualthreads

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java.orig line 1:

> 1: /*

I guess, this temporary file was checked in by a mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2088347385

From sspitsyn at openjdk.org  Wed May 14 08:22:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:22:03 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v4]
In-Reply-To: <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
Message-ID: <wr-Az4gNZaRpBdzgiuuBhmRkpq89XiRQQTJuyUiBUMg=.59e2ab53-a2e2-430d-8538-636691cc6121@github.com>

On Tue, 13 May 2025 04:01:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the set of tests that need to be run with -includevirtualthreads

Looks okay in general. Many files still need a copyright update.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2879245742

From sspitsyn at openjdk.org  Wed May 14 08:25:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:25:17 GMT
Subject: RFR: 8353496: SuspendResume1.java and SuspendResume2.java timeout
 after JDK-8319447
In-Reply-To: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
References: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
Message-ID: <2K6PVPBteGb4Rs8EQEjjoSuwD0sWmKtpb5lRw_bN7w4=.f52eafce-bf3d-45ef-9100-f9e300506690@github.com>

On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
> The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.
> 
> Testing:
> - Mach5 test runs of the fixed tests

Chris and Alan, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25194#issuecomment-2879256263

From sspitsyn at openjdk.org  Wed May 14 08:25:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 08:25:20 GMT
Subject: Integrated: 8353496: SuspendResume1.java and SuspendResume2.java
 timeout after JDK-8319447
In-Reply-To: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
References: <G3zKEwNEyE_ec6R69RFWxdPMcDy1KeiW2cXB9dpJzy8=.f944383f-6b54-4e84-84b6-6840bf2d62b6@github.com>
Message-ID: <iRCOP11u1tV2ILRWTKl4G1qwYHHdoe5WmLcd2ThJ10o=.192dba78-b809-411b-a8bc-72227b83cf3d@github.com>

On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are intermittently failed with a timeout (deadlock). The tests run with `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier. The short sleep in `TestedThread.run` isn't sufficient to make progress. This will happen if tasks pushed by the delayed scheduler are executing before the tasks for the newly started virtual thread. FJP won't search other submission queues until the queue it keeps going back to is empty or there is contention. These deadlocks can be made better reproducible if the sleep in `TestedThread.run` is made minimal (1 millisecond).
> The fix is to increase the sleep to 50 milliseconds and also to decrease the busy part of the busy loop.
> 
> Testing:
> - Mach5 test runs of the fixed tests

This pull request has now been integrated.

Changeset: 265bc5f4
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/265bc5f47d4c0b973fd09d3c2d7576f5f786399f
Stats:     12 lines in 3 files changed: 0 ins; 0 del; 12 mod

8353496: SuspendResume1.java and SuspendResume2.java timeout after JDK-8319447

Reviewed-by: cjplummer, alanb

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

PR: https://git.openjdk.org/jdk/pull/25194

From rvansa at openjdk.org  Wed May 14 09:14:56 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 14 May 2025 09:14:56 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
Message-ID: <aHHDaHTMWR_N6mNGP8mTq21_SOq_jAYQCXGdAIo1u_k=.0493ff5e-c8fe-481f-a23d-3fb32b38109d@github.com>

On Mon, 5 May 2025 06:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to static final var

Yesterday I started working on keeping the original order, but having that independently in InstanceKlass felt really awkward. And since it would mean adding 4 bytes for each field... I would prefer having all the information in the field stream.
Instead, I am now trying to keep the field order, and only create a list of <stream position, field index> sorted by the name & signature instead of the jump table. That has about the same memory requirements (2 or 3 bytes for stream position, 1 or 2 bytes for field index), and is more conservative towards unexpected consequences of reordering the fields.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2879432845

From schernyshev at openjdk.org  Wed May 14 09:31:53 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 14 May 2025 09:31:53 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
Message-ID: <etY25QNWmOPz3ovbQ_tS9CzfvusgoUpZIREMBTfV7Ow=.b37b286a-3e18-4dea-8bf3-eaabcf21791a@github.com>

On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

please go to `Files changed` panel and press Review Changes -> Submit review

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

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2879489346

From schernyshev at openjdk.org  Wed May 14 09:44:52 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 14 May 2025 09:44:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166:

> 164:             return null;
> 165:         }
> 166:     }

Do you still need this method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2088524580

From sspitsyn at openjdk.org  Wed May 14 10:54:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 May 2025 10:54:51 GMT
Subject: RFR: 8356177: Regression after JDK-8352180
In-Reply-To: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
Message-ID: <wOQedzEwBfmgCvQRMikFW_GGTCuoYa6oFc8F9tBGUiQ=.1739425a-11f6-488b-9018-48d663a048b1@github.com>

On Tue, 13 May 2025 20:49:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
> 
> Testing: tier1..4,hs-tier5-svc

This looks good but posted one question.

test/hotspot/jtreg/serviceability/attach/FailedDequeueTest.java line 64:

> 62:         } catch (IOException ex) {
> 63:             System.out.println("OK: setFlag thrown expected exception:");
> 64:             ex.printStackTrace(System.out);

Nit: If an `IOException` is expected then should we report a test failure after the line 61 in a case `IOException` was not thrown?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2839712737
PR Review Comment: https://git.openjdk.org/jdk/pull/25219#discussion_r2088653595

From sjohanss at openjdk.org  Wed May 14 12:26:54 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 14 May 2025 12:26:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v2]
In-Reply-To: <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>
Message-ID: <R_rxLKXQrE05ftpeZniBdXH2s7s8Of4JkcKaQrUInsU=.00bbb53e-36e9-4587-a9e6-b33b4b2515e3@github.com>

On Tue, 13 May 2025 08:33:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Re-enable tests after merge
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Looks great :)

Suggestion to name it `reset_after_sample(...)` instead of `reset_after_sampling(...)` to be more consistent.

src/hotspot/share/runtime/threadHeapSampler.cpp line 440:

> 438:   pick_next_sample();
> 439: 
> 440:   reset_after_sampling(tlab_top);

Suggestion:

  reset_after_sample(tlab_top);

src/hotspot/share/runtime/threadHeapSampler.hpp line 110:

> 108:   }
> 109: 
> 110:   void reset_after_sampling(HeapWord* tlab_top) {

Suggestion:

  void reset_after_sample(HeapWord* tlab_top) {

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2839968906
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2088811246
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2088810407

From rvansa at openjdk.org  Wed May 14 12:46:41 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 14 May 2025 12:46:41 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:

 - Revert change in array.hpp
 - Revert changes in VerifyRawIndexesTest
 - Improve FieldInfo::print
 - Load constant for SORTED_FIELD_TABLE_THRESHOLD
 - Replace JumpTable with SortedFieldTable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/7fb8d340..148802fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=03-04

  Stats: 273 lines in 11 files changed: 115 ins; 106 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From stefank at openjdk.org  Wed May 14 12:47:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 May 2025 12:47:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/0485cd2f..a318053e

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

PR: https://git.openjdk.org/jdk/pull/25114

From stefank at openjdk.org  Wed May 14 12:47:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 May 2025 12:47:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <SN1mWdNqyukzv9ea5GhfzofjH8czSVEv1DKgJlwziNs=.29311f5c-1042-4e19-a037-fadc6ca688a4@github.com>

On Wed, 14 May 2025 12:43:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Thanks for reviewing and pair-fixing!

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2840036844

From rvansa at openjdk.org  Wed May 14 12:54:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 14 May 2025 12:54:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <pjw_BQ3yPMtobDz51NPY9JtamYYhLMmAr9gCuX1hUOk=.8abd27ec-1482-429c-9eb5-c20eb5d9a8d7@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <pjw_BQ3yPMtobDz51NPY9JtamYYhLMmAr9gCuX1hUOk=.8abd27ec-1482-429c-9eb5-c20eb5d9a8d7@github.com>
Message-ID: <rUcNzh3vvuADsi8CIqvz1kPk4mBFQaDQF10I-nRfw50=.1c577e9e-4a9f-45ac-b3c6-e9c5b8b9f758@github.com>

On Tue, 13 May 2025 11:39:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move constant to static final var
>
> Also can you include this:
> 
> diff --git a/src/hotspot/share/oops/fieldInfo.cpp b/src/hotspot/share/oops/fieldInfo.cpp
> index 300b45277ad..7668faf6187 100644
> --- a/src/hotspot/share/oops/fieldInfo.cpp
> +++ b/src/hotspot/share/oops/fieldInfo.cpp
> @@ -37,8 +37,8 @@ void FieldInfo::print(outputStream* os, ConstantPool* cp) {
>                  field_flags().as_uint(),
>                  initializer_index(),
>                  generic_signature_index(),
> -                _field_flags.is_injected() ? lookup_symbol(generic_signature_index())->as_utf8() : cp->symbol_at(generic_signature_index())->as_utf8(),
> -                contended_group());
> +                field_flags().is_generic() ? cp->symbol_at(generic_signature_index())->as_utf8() : "",
> +                is_contended() ? contended_group() : 0);
>  }
>  
> 
> which I fixed for printing.
> 
> Also, sorting the fields is inlined code in parse_fields.  Can you make it it's own method?  And it seems to sort the fields before the injected fields are added, so how do you find the injected fields?  I think injected fields aren't added to klasses with >16 fields maybe?
> 
> I was going to write a test with JVMTI GetFields and > 16 fields because I'm not sure how/if you're fixing the order that the fields are returned by that API.

@coleenp @SirYwell Based on the feedback and considerations from your reviews, I've pushed a version that does not reorder fields. The `CCC` test shows the same performance as the original PR, in case of huge class the improvement is even better (0.23 s vs 0.5 s). The price for O(log(N)) field lookup is 3 bytes per field for medium classes (17 - 256 non-injected fields), 4-5 bytes for bigger classes.
Due to not reordering the fields at all the chance for regression is significantly lower. I have not executed the whole JCK but tried the mentioned test and it does pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2880137455

From ihse at openjdk.org  Wed May 14 14:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:34:37 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8
Message-ID: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>

After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

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

Commit messages:
 - 8356978: Convert unicode sequences in Java source code to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25229/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356978
  Stats: 9616 lines in 90 files changed: 0 ins; 0 del; 9616 mod
  Patch: https://git.openjdk.org/jdk/pull/25229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229

PR: https://git.openjdk.org/jdk/pull/25229

From iklam at openjdk.org  Wed May 14 16:07:50 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 16:07:50 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <kqhCPc0be_lUwxRPycPf41J5Dw2ZT_V9p-hW5e78RV0=.fe150ef3-decd-4604-a4f5-ace3710a8c8c@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>
 <-HkCpXlfsip8P6WTmrVqjb6ZhD10RrhGdKUqf1VETIk=.26ce21f4-47f2-493c-98e7-d1dfdfbab638@github.com>
 <kqhCPc0be_lUwxRPycPf41J5Dw2ZT_V9p-hW5e78RV0=.fe150ef3-decd-4604-a4f5-ace3710a8c8c@github.com>
Message-ID: <LgRxn1dhGl8HD2RZPV5msyq1QxPimAIoeN46rYftyt8=.d918bd5d-1db2-447a-a1c8-52eab28b4d0c@github.com>

On Wed, 14 May 2025 02:21:39 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>>> Instead of intercepting here would it be better if we can clear `JvmtiAgentList::_list` in `CDSConfig::check_aotmode_create()`?
>> 
>> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
>> 
>> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
>> 
>> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.
>
>> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
>> 
>> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
>> 
> 
> It looks like the memory for these entries is never freed even after unloading the agents during shutdown. So there memory is never reclaimed. And setting `JvmtiAgentList::_list` to nullptr is not really changing that behavior. 
> 
>> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.
> 
> hmmm...not sure about that. Ideally we should ignore the jvmti options that add agents if the JVM is in assembly phase. But we detect the assembly phase after jvmti options have been processed.
> IMO clearing the _list is the next best approach. If that doesn't work then more intrusive fix like intercepting the `JvmtiAgentList::Iterator`.

I cleared the `_list` as you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2089285551

From iklam at openjdk.org  Wed May 14 16:32:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 16:32:10 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v5]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <VIAmbWXcRKSdNQRCIuw_EQT-GV0dAzSsA5IcaU88wSg=.9fb5164a-5375-4099-8051-5ea362b59cdc@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora review - fixed typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/dddf591d..37d334a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/25136

From iklam at openjdk.org  Wed May 14 16:44:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 16:44:56 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <sY8shShCouTchqSxnDZ2wXfaNLanZHGrAZUAU8wo1SE=.c17f6346-7165-4c14-b75a-a455d2aafd18@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
 <sY8shShCouTchqSxnDZ2wXfaNLanZHGrAZUAU8wo1SE=.c17f6346-7165-4c14-b75a-a455d2aafd18@github.com>
Message-ID: <xN8aBXSzXi5GC_AhVAWSvzOY3zdetNVwdkjyTytfTA8=.72b33027-2f77-4af9-a43d-b7da12ba48f6@github.com>

On Wed, 14 May 2025 03:55:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But given you state that CDS is a subset of AOT - the AOT for metaspace - does it really make sense to simply rebadge "cds" logging as "aot"? It seems to me that "aot" logging will generate massive amounts of data if everything AOT related logs when "aot" is used. Would you not want finer-grained logging such that "cds" becomes "aot+metaspace" as described?

Many "cds" logs already have sub-levels. E.g., `[cds][heap]`, `[cds][module]`. The top-level `[cds]` log are used for general trouble shooting (e.g, the CDS archive cannot be mapped). Today, if you run with -Xlog:cds, there's a fair amount of logs but not massive:


$ java -Xlog:cds --version 
[0.003s][info][cds] trying to map /jdk3/bld/tin/images/jdk/lib/server/classes.jsa
[0.003s][info][cds] Opened shared archive file /jdk3/bld/tin/images/jdk/lib/server/classes.jsa.
[0.003s][info][cds] The shared archive file was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 0
[0.003s][info][cds] Core region alignment: 4096
[0.003s][info][cds] ArchiveRelocationMode: 1
[0.003s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address
[0.003s][info][cds] Try to map archive(s) at an alternative address
[0.003s][info][cds] Reserved archive_space_rs [0x000073d7fa000000 - 0x000073d7fb000000] (16777216) bytes (includes protection zone)
[0.003s][info][cds] Reserved class_space_rs   [0x000073d7fb000000 - 0x000073d83b000000] (1073741824) bytes
[0.003s][info][cds] Mapped static  region #0 at base 0x000073d7fa001000 top 0x000073d7fa48b000 (ReadWrite)
[0.003s][info][cds] Mapped static  region #1 at base 0x000073d7fa48b000 top 0x000073d7fad37000 (ReadOnly)
[0.003s][info][cds] Mapped static  region #2 at base 0x000073d88b5ce000 top 0x000073d88b600000 (Bitmap)
[0.005s][info][cds] archived module property jdk.module.main: (null)
[0.005s][info][cds] archived module property jdk.module.addexports: (null)
[0.005s][info][cds] archived module property jdk.module.addmods: (null)
[0.005s][info][cds] archived module property jdk.module.enable.native.access: (null)
[0.005s][info][cds] archived module property jdk.module.addopens: (null)
[0.005s][info][cds] optimized module handling: enabled
[0.005s][info][cds] full module graph: enabled
[0.005s][info][cds] CDS archive was created with max heap size = 128M, and the following configuration:
[0.005s][info][cds]     narrow_klass_base at mapping start address, narrow_klass_pointer_bits = 32, narrow_klass_shift = 0
[0.005s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
[0.005s][info][cds] The current max heap size = 15488M, G1HeapRegion::GrainBytes = 8388608
[0.005s][info][cds]     narrow_klass_base = 0x000073d7fa000000, arrow_klass_pointer_bits = 32, narrow_klass_shift = 0
[0.005s][info][cds]     narrow_oop_mode = 1, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 3
[0.005s][info][cds]     heap range = [0x0000000438000000 - 0x0000000800000000]
[0.005s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
[0.005s][info][cds] Heap data mapped at 0x00000007ff800000, size =  1157176 bytes
[0.005s][info][cds] CDS heap data relocation delta = 30058479616 bytes
[0.005s][info][cds] use_full_module_graph = true; java.base = 0x000073d7fa4860a8
[0.005s][info][cds] patching heap embedded pointers: narrowOop 0xffe00000 -> 0xfff00000
[0.005s][info][cds] CDS heap data quick relocation not possible
[0.005s][info][cds] Unmapping region #2 at base 0x000073d88b5ce000 (Bitmap)


Going forward, we may change some of the logs to add an extra level if it makes sense. At this point, I don't see any logs that need immediate attention:


$ java -Xlog:logging=debug
[....]
[0.009s][debug][logging] Available tag sets: , aot, aot+class, aot+codecache, aot+codecache+exit, aot+codecache+init, aot+codecache+reloc, aot+codecache+stringtable, aot+codecache+stubs, aot+hashtables, aot+heap, aot+heap+mirror, aot+init, aot+jvmti, aot+lambda, aot+link, aot+load, aot+mirror, aot+ref, aot+reloc, aot+unshareable, arguments, attach, cds, cds+class, cds+dynamic, cds+hashtables, cds+init, cds+lambda, cds+map, cds+map+oops, cds+module, cds+reloc, cds+resolve, cds+verification, cds+vtables,


> I'm undecided whether this aspect of the work requires a CSR request ... but it never hurts to have one. Obviously in 26 there will be one for the actual deprecation/obsoletion/expiration process.

Since most of the logs are for diagnostic purposes and are often changed along with the VM code, I think it's not necessary for a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25136#issuecomment-2880887150

From iklam at openjdk.org  Wed May 14 16:53:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 16:53:10 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v6]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <KB_C01fxaar5m_dmQl4wh5Ub6YTGZkij17i3uwYM5cg=.c1562fe4-48a4-4caa-84cf-427e0041d010@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. I will create a second PR that coverts the rest of the logs.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Improved comments: [cds] logs will be printed if no -XX:AOTxxx flags are used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/37d334a6..8205506a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=04-05

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From iklam at openjdk.org  Wed May 14 16:53:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 16:53:11 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot [v4]
In-Reply-To: <sY8shShCouTchqSxnDZ2wXfaNLanZHGrAZUAU8wo1SE=.c17f6346-7165-4c14-b75a-a455d2aafd18@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
 <sY8shShCouTchqSxnDZ2wXfaNLanZHGrAZUAU8wo1SE=.c17f6346-7165-4c14-b75a-a455d2aafd18@github.com>
Message-ID: <D-swnc1YsvchkFsgrgwJKkPn5W7GQ2t7KhczfhZjSkM=.a510d669-46c1-431e-aa5f-31092a8c9be6@github.com>

On Wed, 14 May 2025 03:45:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed PrintAOTLogsAsCDSLogs and improved comments
>
> src/hotspot/share/cds/aotLogging.hpp line 63:
> 
>> 61: // The messages printed with the log_aot_xxx() macros work as if they are
>> 62: // using the [cds] tag when running with the "classic" CDS flags such as
>> 63: // -XX:SharedArchiveFile:
> 
> What if you specify no flags and rely on the implicit settings e.g. `-Xshare:auto`, will `-Xlog:cds` continue to work as today?

I updated the comments to flip the condition -- if no `-XX:AOTxxx` flag are used, we print the `[cds]` decorations.

The new AOT workflow requires the use of at least one flag that starts with `-XX:AOT`. There's no implicit use of AOT features.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2089355725

From cjplummer at openjdk.org  Wed May 14 17:09:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:09:55 GMT
Subject: RFR: 8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java
 fails sometimes on macOS
In-Reply-To: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
References: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
Message-ID: <6GH0KbrnJdKXlwxYsnp__S5yR3jTl-lL9I4IaNat6BA=.6b40a9b5-3f66-418f-b74b-64f880c8ccfe@github.com>

On Fri, 9 May 2025 20:59:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.
> 
> Tested by running test on all supported platforms.

Thanks for the reviews Kevin, Alex, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25156#issuecomment-2880951011

From cjplummer at openjdk.org  Wed May 14 17:09:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:09:56 GMT
Subject: Integrated: 8356641: Test
 com/sun/jdi/EarlyThreadGroupChildrenTest.java fails sometimes on macOS
In-Reply-To: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
References: <9Zwr0yTxJc5Hv1WRwhQO3IFKFQBWyswLPEdNoHueZUs=.f06c2970-24e5-4bb9-b0c6-b674536d17be@github.com>
Message-ID: <rUa0HDC-9lNQMhsfL00oDwoe5l4INGQgiYWsTObRKzU=.a542c898-3ac9-4221-b6a7-039ad7bf6ec2@github.com>

On Fri, 9 May 2025 20:59:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> We need to wait until after the VMStart event has arrived before adding the listener. Otherwise if the listener is already installed before the VMStart arrives, it will result in resuming the debuggee after processing the VMStart. We want the debuggee to remain suspended after handling the VMStart. More details in the CR.
> 
> Tested by running test on all supported platforms.

This pull request has now been integrated.

Changeset: a2628357
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2628357a922b1ea9ba721b1d8b708ff91d46d76
Stats:     9 lines in 1 file changed: 6 ins; 3 del; 0 mod

8356641: Test com/sun/jdi/EarlyThreadGroupChildrenTest.java fails sometimes on macOS

Reviewed-by: kevinw, amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25156

From cjplummer at openjdk.org  Wed May 14 17:12:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:12:52 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v4]
In-Reply-To: <wr-Az4gNZaRpBdzgiuuBhmRkpq89XiRQQTJuyUiBUMg=.59e2ab53-a2e2-430d-8538-636691cc6121@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <UHPqH2AAqBcnMH6cciuCVEKdshShy9UBi81OZVUa21A=.87173e05-6fe1-4231-83e2-33fad669929c@github.com>
 <wr-Az4gNZaRpBdzgiuuBhmRkpq89XiRQQTJuyUiBUMg=.59e2ab53-a2e2-430d-8538-636691cc6121@github.com>
Message-ID: <NN3b-FpSsNA6o-ReOjGTI92C1YEer5GX9lz-PcqOMwM=.7b8182e2-4cba-4900-8aad-1c088fc849a5@github.com>

On Wed, 14 May 2025 08:19:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Looks okay in general. Many files still need a copyright update.

I'll update after the merge with 2 other PRs that this PR is dependent on.

> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq002.java line 251:
> 
>> 249:         String lineForComm  = "lineForComm";
>> 250: 
>> 251:         //ThreadReference   mainThread = debuggee.threadByNameOrThrow("main");
> 
> Q: Do you want to keep this commented out line?

I thought I had undone that. This test is fixed in another PR, but I had experimented with the fix here first. I'll remove it.

> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java.orig line 1:
> 
>> 1: /*
> 
> I guess, this temporary file was checked in by a mistake.

Good catch. At some point I did a "git add -a", not knowing that this filing was lingering around. I'll remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2880959336
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2089384545
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2089386062

From cjplummer at openjdk.org  Wed May 14 17:16:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:16:31 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v5]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <0G6Fej3smu-5glcXPQqFNMpjSbDP1kVATWC0eAEdsAQ=.bb08cc9e-24bc-4625-84e0-f2847882dc74@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - remove mistaken edit
 - Remove mistakenly added file.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/dcc5c67b..7aa6b518

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=03-04

  Stats: 787 lines in 2 files changed: 0 ins; 786 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From cjplummer at openjdk.org  Wed May 14 17:21:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:21:37 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v6]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <kAW9XrO2ntpiU_uGOHFApyVBazS_BaLNYaSQtAqtuSw=.c77293e8-0800-4b24-a933-515c28cee91b@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  remove mistaken edit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/7aa6b518..599aae6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/24606

From cjplummer at openjdk.org  Wed May 14 17:42:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 17:42:27 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v7]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <6RBr-oNS5owKpLziXGg92SH1ZCJMZl3ePH2GF-RbGsc=.d6ffed1a-d9e5-4fcf-9160-f506e5b52dbc@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix broken copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/599aae6c..5bac9077

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/24606

From cjplummer at openjdk.org  Wed May 14 18:14:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 18:14:56 GMT
Subject: RFR: 8356588: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 3
In-Reply-To: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
References: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
Message-ID: <dpGEirb85rluSLMzV1rm4-xIVg2wdf9mNVQm6nAkB0g=.bce22f95-e5cb-4bb3-bd7e-2b63d900761c@github.com>

On Thu, 8 May 2025 21:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There were a small number of tests that were missed with [JDK-8356023](https://bugs.openjdk.org/browse/JDK-8356023) (part 2). Most of these tests are ones that were calling vm.allThreads() directly to search for the needed thread rather than relying on findThreadByNameOrThrow().
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25132#issuecomment-2881112356

From cjplummer at openjdk.org  Wed May 14 18:14:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 18:14:56 GMT
Subject: Integrated: 8356588: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 3
In-Reply-To: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
References: <Cq3WHbTFrDD96n--x_o474Tv_efP9eXG8T9wGgG7u2k=.8d32a842-6d19-49f5-b05f-4a55f40e2445@github.com>
Message-ID: <jz5gRKGndEdAcIHFAJz2bFuxDReF2V-ubPR6qV0l1i4=.a93a504c-7ce5-4f01-b395-1a0e588f4379@github.com>

On Thu, 8 May 2025 21:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There were a small number of tests that were missed with [JDK-8356023](https://bugs.openjdk.org/browse/JDK-8356023) (part 2). Most of these tests are ones that were calling vm.allThreads() directly to search for the needed thread rather than relying on findThreadByNameOrThrow().
> 
> Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

This pull request has now been integrated.

Changeset: 75504a35
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75504a35ee663625982f8aed508e5ff562643334
Stats:     428 lines in 35 files changed: 75 ins; 272 del; 81 mod

8356588: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 3

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25132

From cjplummer at openjdk.org  Wed May 14 18:33:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 18:33:52 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4
In-Reply-To: <8mn28z_GYTH9IwYstb1uIAMW9OvQXtb3_FRzsWyYYCU=.0b647309-12ea-4b92-b659-1c04d10feb92@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
 <8mn28z_GYTH9IwYstb1uIAMW9OvQXtb3_FRzsWyYYCU=.0b647309-12ea-4b92-b659-1c04d10feb92@github.com>
Message-ID: <yL3Vu5xGUPvBAJixdkQiRPOfVeuo_9O_2iCxjgDFFrM=.6b38b60b-f58d-496d-94de-d8bdcf9a0986@github.com>

On Tue, 13 May 2025 22:37:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue005/setvalue005.java line 165:
>> 
>>> 163:             debuggee.threadByFieldName(rType, "mainThread", DEBUGGEE_THRDNAME);
>>> 164:         if (thrRef == null) {
>>> 165:             log.complain("TEST FAILURE: method Debugee.threadByName() returned null for debuggee thread "
>> 
>> Need to update error message
>> BTW `debuggee.classByName` also can throw exceptions, need to catch and call `quitDebuggee()` (this applicable to other changes in the fix when `debuggee.classByName` is called outside of try block)
>
> This is a common pattern in my changes. I'l need to add something like the following catch:
> 
> 
>         } catch (Exception e) {
>             e.printStackTrace();
>             log.complain("TEST FAILURE: caught unexpected exception: " + e);
>             tot_res = Consts.TEST_FAILED;
>         }
> 
> 
> It would have been a lot cleaner if these tests were all written to just let the exception happen and not worry about printing messages about what it was doing when the exception was thrown. The exception stack trace provides all the info you need.
> 
> The error handling in these tests is frustrating to work with. It's inconsistent and incomplete. Many catch exceptions, print a failure message (and no exception backtrace), and them resume at the next step, only to hang as a result.
> 
> I was tempted to get rid of a lot of the failure handling when thrRef == null and just use threadByFieldNameOrThrow() instead of threadByFieldName(), but also wanted to limit the scope of the changes. I did observe that in general this works well. While making the changes for this PR I dealt with a lot of failures due to calling threadByFieldNameOrThrow() with bad args, and the test always failed quickly and gracefully. But in the end I changed to threadByFieldName() to keep things a bit more consistent.

Actually debuggee.classByName() returns null if the class is not found, and callers typically do not check for this, which results in an NPE later on. debuggee.classByName() can also throw an exception if it discovers something like multiple matches for the class name.

I'm not so sure the added error handling is of any real benefit here, and just adds to the already overdone error handling. Exceptions seem to properly result in a quick exit, and in fact it is the error handling that can result in not exiting quickly due to trying to sync with the debuggee. I'd like to request not having to add additional checks when calling debuggee.classByName()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2089514774

From amenkov at openjdk.org  Wed May 14 18:33:42 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 May 2025 18:33:42 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
Message-ID: <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>

> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25219/files
  - new: https://git.openjdk.org/jdk/pull/25219/files/74c68070..ee6026a8

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

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

PR: https://git.openjdk.org/jdk/pull/25219

From cjplummer at openjdk.org  Wed May 14 18:44:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 May 2025 18:44:51 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
 <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
Message-ID: <fi1YiqnogMxVe0zHkrV6sukIqC2c-GoQ96jPeZxUro0=.f93c8adb-10ef-48d6-a5db-5220ff526ee5@github.com>

On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2841168920

From amenkov at openjdk.org  Wed May 14 19:04:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 May 2025 19:04:56 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <wOQedzEwBfmgCvQRMikFW_GGTCuoYa6oFc8F9tBGUiQ=.1739425a-11f6-488b-9018-48d663a048b1@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
 <wOQedzEwBfmgCvQRMikFW_GGTCuoYa6oFc8F9tBGUiQ=.1739425a-11f6-488b-9018-48d663a048b1@github.com>
Message-ID: <4fqz9rE_tJAI1cTGSLNrNICD9KY71P23jTqNmdIlXk0=.9bbcd940-7784-416e-8d47-95a40ce5f73f@github.com>

On Wed, 14 May 2025 10:51:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/serviceability/attach/FailedDequeueTest.java line 64:
> 
>> 62:         } catch (IOException ex) {
>> 63:             System.out.println("OK: setFlag thrown expected exception:");
>> 64:             ex.printStackTrace(System.out);
> 
> Nit: If an `IOException` is expected then should we report a test failure after the line 61 in a case `IOException` was not thrown?

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25219#discussion_r2089558850

From amenkov at openjdk.org  Wed May 14 19:29:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 May 2025 19:29:51 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4
In-Reply-To: <yL3Vu5xGUPvBAJixdkQiRPOfVeuo_9O_2iCxjgDFFrM=.6b38b60b-f58d-496d-94de-d8bdcf9a0986@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
 <8mn28z_GYTH9IwYstb1uIAMW9OvQXtb3_FRzsWyYYCU=.0b647309-12ea-4b92-b659-1c04d10feb92@github.com>
 <yL3Vu5xGUPvBAJixdkQiRPOfVeuo_9O_2iCxjgDFFrM=.6b38b60b-f58d-496d-94de-d8bdcf9a0986@github.com>
Message-ID: <RT46gRixjj1yb40nITwtPjS7qZrYtPSswQA0s_luIKs=.f1e6a48c-5b49-4ffa-9daa-0dae67fc5028@github.com>

On Wed, 14 May 2025 18:30:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not so sure the added error handling is of any real benefit here, and just adds to the already overdone error handling. Exceptions seem to properly result in a quick exit, and in fact it is the error handling that can result in not exiting quickly due to trying to sync with the debuggee.

My concern is about debugee process. I'm not sure all tests have a debugees which exits shortly after the debugger disconnects. So we can get stale debuggee processes on test failures

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2089597600

From iklam at openjdk.org  Wed May 14 21:03:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 21:03:35 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent [v2]
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <MgXgs0ZdZfGt_MyrIDO508U_hKW_ue-516aG0eIj0s8=.1d82c53e-77bd-4ab0-8232-6fa01ae4ab1c@github.com>

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

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

 - Merge branch 'master' into 8356693-aot-assembly-phase-fails-with-java-agent
 - @ashu-mehra comments
 - fixed whitespace
 - 8356693: AOT assembly phase fails with -javaagent
 - step1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25170/files
  - new: https://git.openjdk.org/jdk/pull/25170/files/295fd085..191a950d

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

  Stats: 16306 lines in 661 files changed: 8380 ins; 4320 del; 3606 mod
  Patch: https://git.openjdk.org/jdk/pull/25170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25170/head:pull/25170

PR: https://git.openjdk.org/jdk/pull/25170

From asmehra at openjdk.org  Wed May 14 21:15:53 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 May 2025 21:15:53 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent [v2]
In-Reply-To: <MgXgs0ZdZfGt_MyrIDO508U_hKW_ue-516aG0eIj0s8=.1d82c53e-77bd-4ab0-8232-6fa01ae4ab1c@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <MgXgs0ZdZfGt_MyrIDO508U_hKW_ue-516aG0eIj0s8=.1d82c53e-77bd-4ab0-8232-6fa01ae4ab1c@github.com>
Message-ID: <oV0rSI2cjcRm69_gOGHd5Ep3w4MNYLO_I3JhuS0slPU=.03b014c3-7373-4ff5-bf2c-471254a97aea@github.com>

On Wed, 14 May 2025 21:03:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> https://openjdk.org/jeps/483 mentions:
>> 
>>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
>> 
>> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
>> 
>> 
>> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
>> Error occurred during CDS dumping
>> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
>> 
>> 
>> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
>> 
>> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
>> 
>> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
>> 
>> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8356693-aot-assembly-phase-fails-with-java-agent
>  - @ashu-mehra comments
>  - fixed whitespace
>  - 8356693: AOT assembly phase fails with -javaagent
>  - step1

Marked as reviewed by asmehra (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25170#pullrequestreview-2841532608

From asmehra at openjdk.org  Wed May 14 21:15:53 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 May 2025 21:15:53 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent [v2]
In-Reply-To: <LgRxn1dhGl8HD2RZPV5msyq1QxPimAIoeN46rYftyt8=.d918bd5d-1db2-447a-a1c8-52eab28b4d0c@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <H_F68zwyVr2cfE2D3ZbzJaU4k1_Nfi65mr8hbATrBj8=.0d421c9d-120c-4bad-a267-b7f7afa87128@github.com>
 <-HkCpXlfsip8P6WTmrVqjb6ZhD10RrhGdKUqf1VETIk=.26ce21f4-47f2-493c-98e7-d1dfdfbab638@github.com>
 <kqhCPc0be_lUwxRPycPf41J5Dw2ZT_V9p-hW5e78RV0=.fe150ef3-decd-4604-a4f5-ace3710a8c8c@github.com>
 <LgRxn1dhGl8HD2RZPV5msyq1QxPimAIoeN46rYftyt8=.d918bd5d-1db2-447a-a1c8-52eab28b4d0c@github.com>
Message-ID: <0eTtTvaui_BlNOFi-48UqzIyZ1QYHgtgdtOvs-wdaps=.75de8e08-a264-4b25-9887-59a0a8d67ae3@github.com>

On Wed, 14 May 2025 16:05:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
>>> 
>>> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
>>> 
>> 
>> It looks like the memory for these entries is never freed even after unloading the agents during shutdown. So there memory is never reclaimed. And setting `JvmtiAgentList::_list` to nullptr is not really changing that behavior. 
>> 
>>> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.
>> 
>> hmmm...not sure about that. Ideally we should ignore the jvmti options that add agents if the JVM is in assembly phase. But we detect the assembly phase after jvmti options have been processed.
>> IMO clearing the _list is the next best approach. If that doesn't work then more intrusive fix like intercepting the `JvmtiAgentList::Iterator`.
>
> I cleared the `_list` as you suggested.

@iklam thank you for addressing my comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2089762404

From iklam at openjdk.org  Wed May 14 21:51:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 21:51:10 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v7]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <pZsFI1aNYl7BrnPKThKvX3Obe5A36enOtn5LPHs0bzQ=.af1bda69-dc2e-4f0e-ba53-4c2dbc059d33@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Fixed makefile; Fixed copyright
 - Merge branch 'master' into 8356595-convert-cds-log-to-aot-log
 - Improved comments: [cds] logs will be printed if no -XX:AOTxxx flags are used
 - @dholmes-ora review - fixed typos
 - Removed PrintAOTLogsAsCDSLogs and improved comments
 - More conversion; clean up; bug fixes
 - Fixed macos build
 - @stefank suggestions
 - Merge remote-tracking branch '8355638-xlog-aot-as-alias-for-xlog-cds' into 8355638-xlog-aot-as-alias-for-xlog-cds-alt-impl
 - Removed checks for error message that got removed from the PR
 - ... and 17 more: https://git.openjdk.org/jdk/compare/948ade8e...278ab150

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

Changes: https://git.openjdk.org/jdk/pull/25136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=06
  Stats: 714 lines in 48 files changed: 313 ins; 9 del; 392 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From ccheung at openjdk.org  Wed May 14 21:53:51 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 14 May 2025 21:53:51 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent [v2]
In-Reply-To: <MgXgs0ZdZfGt_MyrIDO508U_hKW_ue-516aG0eIj0s8=.1d82c53e-77bd-4ab0-8232-6fa01ae4ab1c@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <MgXgs0ZdZfGt_MyrIDO508U_hKW_ue-516aG0eIj0s8=.1d82c53e-77bd-4ab0-8232-6fa01ae4ab1c@github.com>
Message-ID: <eH2_k3fyE41y-pWLHkZAX4JXBn_wQOsrlfdCfhVY6So=.d8107f6a-aa2b-42fa-826c-df9103a0f5cf@github.com>

On Wed, 14 May 2025 21:03:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> https://openjdk.org/jeps/483 mentions:
>> 
>>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
>> 
>> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
>> 
>> 
>> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
>> Error occurred during CDS dumping
>> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
>> 
>> 
>> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
>> 
>> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
>> 
>> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
>> 
>> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8356693-aot-assembly-phase-fails-with-java-agent
>  - @ashu-mehra comments
>  - fixed whitespace
>  - 8356693: AOT assembly phase fails with -javaagent
>  - step1

Looks good.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25170#pullrequestreview-2841595350

From iklam at openjdk.org  Wed May 14 22:04:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 22:04:04 GMT
Subject: RFR: 8356693: AOT assembly phase fails with -javaagent [v2]
In-Reply-To: <84C5B5W01zqy7tLm8rbbx4OpfkjwvTL2drEEOnrB5p4=.58c24a93-b87c-43ba-920e-1d7859a69923@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
 <84C5B5W01zqy7tLm8rbbx4OpfkjwvTL2drEEOnrB5p4=.58c24a93-b87c-43ba-920e-1d7859a69923@github.com>
Message-ID: <FHWwrWq97kEps9JwG_9jqGWEZ_vt2RD8RxzdziS6AUk=.bd0dac98-e0a6-4ba2-819e-99e104a2bfe6@github.com>

On Tue, 13 May 2025 08:50:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8356693-aot-assembly-phase-fails-with-java-agent
>>  - @ashu-mehra comments
>>  - fixed whitespace
>>  - 8356693: AOT assembly phase fails with -javaagent
>>  - step1
>
> All right, looks reasonable.

Thanks @shipilev @ashu-mehra @calvinccheung for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25170#issuecomment-2881684814

From iklam at openjdk.org  Wed May 14 22:04:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 22:04:05 GMT
Subject: Integrated: 8356693: AOT assembly phase fails with -javaagent
In-Reply-To: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
References: <Vw48OwfzsiBr3x4tOlhFO5rCnU_bN-pKAEKXiOPYUiM=.5ad934ae-31bd-451c-84c9-56a14272c6c7@github.com>
Message-ID: <io9u3K8Szrf9VVS0qDMMA2PLgl6A3iFd8WiScbW6lOY=.3aa505f8-82b3-449c-9215-ad3c860dd597@github.com>

On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> https://openjdk.org/jeps/483 mentions:
> 
>> To enjoy the benefits of the AOT cache generated during a training run, the training run and all subsequent runs must be essentially similar. [...] All runs must not use JVMTI agents that can arbitrarily rewrite classfiles  using ClassFileLoadHook.
> 
> However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,
> 
> 
> $ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
> Error occurred during CDS dumping
> Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping
> 
> 
> With the AOT cache, the main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.
> 
> With this PR, we allow JVMTI agents in the AOT workflow. To address the above concern, we ensure that JVMTI agents cannot affect the contents of AOT cache:
> 
> -  In training runs (`java -XX:AOTMode=record`), JVMTI agents are allowed, but the AOT configuration file should filter out classes that are transformed by the agents. This can be checking `InstanceKlass::has_been_redefined()` and `ClassFileStream::from_class_file_load_hook()`.
> 
> - In the assembly phase (`java -XX:AOTMode=record`), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.

This pull request has now been integrated.

Changeset: b66ab8eb
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b66ab8ebe254c674ce6a5b731773c41111fa6bc5
Stats:     253 lines in 12 files changed: 246 ins; 2 del; 5 mod

8356693: AOT assembly phase fails with -javaagent

Reviewed-by: asmehra, ccheung, shade

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

PR: https://git.openjdk.org/jdk/pull/25170

From mseledtsov at openjdk.org  Wed May 14 22:25:52 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 22:25:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <X5GZQz6cnSG4peWbvJD2SmRERl3-FH7u-7nNZCQ8pNU=.fc95cd20-5565-4242-a8fa-38fdbf382af0@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

Overall change looks good to me.
Looks like this method is not in use anymore (as also noted by [sercher]), consider deleting it:
private static String getDockerVersionStr() {

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

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2881725481

From mseledtsov at openjdk.org  Wed May 14 22:44:51 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 22:44:51 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
Message-ID: <uztJg3CEB4-0fGIpOWnNrhxPbaN70HwKdzf91__Gh50=.03f3aa6f-9e6f-454b-bb53-498566fab560@github.com>

On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestDockerMemoryMetricsSubgroup.java
>   
>   remove extra space

Change looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/24930#issuecomment-2881756560

From iveresov at openjdk.org  Wed May 14 23:39:43 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 14 May 2025 23:39:43 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v21]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <fo9XXTc2C77UQRw2_2LghjtdkcM2zxNO5XgasBwF270=.4b72ecd6-f71e-49fe-b47b-7189456f3f3d@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits:

 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
   
   Reviewed-by: vlivanov, kvn
 - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
   
   Reviewed-by: naoto
 - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
   
   Reviewed-by: wkemper
 - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default
   
   Reviewed-by: asemenyuk
 - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
   
   Reviewed-by: naoto, bpb
 - 8356447: Change default for EagerJVMCI to true
   
   Reviewed-by: yzheng, kvn, never
 - ... and 74 more: https://git.openjdk.org/jdk/compare/5e50a584...d3d51b00

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=20
  Stats: 3332 lines in 59 files changed: 3118 ins; 100 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From mseledtsov at openjdk.org  Wed May 14 23:49:50 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 23:49:50 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
Message-ID: <TFX75qyR9yjawIUggVopRB-Bt0Y86x58bSY1Djp280M=.50962f9d-78a9-44b8-98c7-a86804209dc3@github.com>

On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestDockerMemoryMetricsSubgroup.java
>   
>   remove extra space

Marked as reviewed by mseledtsov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2841749929

From iklam at openjdk.org  Thu May 15 02:05:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 May 2025 02:05:57 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v8]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <LM9mEypI_sRqVAcAzzBWBdN-97szXtIXAWBlNSNJStY=.36efd062-fdc3-4cbe-87a7-c713df9d0442@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge master
 - Fixed makefile; Fixed copyright
 - Merge branch 'master' into 8356595-convert-cds-log-to-aot-log
 - Improved comments: [cds] logs will be printed if no -XX:AOTxxx flags are used
 - @dholmes-ora review - fixed typos
 - Removed PrintAOTLogsAsCDSLogs and improved comments
 - More conversion; clean up; bug fixes
 - Fixed macos build
 - @stefank suggestions
 - Merge remote-tracking branch '8355638-xlog-aot-as-alias-for-xlog-cds' into 8355638-xlog-aot-as-alias-for-xlog-cds-alt-impl
 - ... and 18 more: https://git.openjdk.org/jdk/compare/5e50a584...2a4355f8

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

Changes: https://git.openjdk.org/jdk/pull/25136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=07
  Stats: 715 lines in 48 files changed: 313 ins; 9 del; 393 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From dholmes at openjdk.org  Thu May 15 07:33:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 May 2025 07:33:56 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v8]
In-Reply-To: <LM9mEypI_sRqVAcAzzBWBdN-97szXtIXAWBlNSNJStY=.36efd062-fdc3-4cbe-87a7-c713df9d0442@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <LM9mEypI_sRqVAcAzzBWBdN-97szXtIXAWBlNSNJStY=.36efd062-fdc3-4cbe-87a7-c713df9d0442@github.com>
Message-ID: <XPM2RGYKUJa1_YiTUlW08c7XrajHJx_gKybKF8Hct_g=.e7ec5d85-7c31-43a0-a1c3-f60f39beb75e@github.com>

On Thu, 15 May 2025 02:05:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge master
>  - Fixed makefile; Fixed copyright
>  - Merge branch 'master' into 8356595-convert-cds-log-to-aot-log
>  - Improved comments: [cds] logs will be printed if no -XX:AOTxxx flags are used
>  - @dholmes-ora review - fixed typos
>  - Removed PrintAOTLogsAsCDSLogs and improved comments
>  - More conversion; clean up; bug fixes
>  - Fixed macos build
>  - @stefank suggestions
>  - Merge remote-tracking branch '8355638-xlog-aot-as-alias-for-xlog-cds' into 8355638-xlog-aot-as-alias-for-xlog-cds-alt-impl
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/5e50a584...2a4355f8

Okay, nothing further from me. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2842582318

From jsjolen at openjdk.org  Thu May 15 07:33:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 15 May 2025 07:33:57 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v4]
In-Reply-To: <JwsoeT5ad8ix3XdQGF2DSnS72xeQolX_i8EjinYECvc=.2bc76eb3-3f59-4655-a073-0d20456cadc2@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
 <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>
 <JwsoeT5ad8ix3XdQGF2DSnS72xeQolX_i8EjinYECvc=.2bc76eb3-3f59-4655-a073-0d20456cadc2@github.com>
Message-ID: <Y4g3Hkvw71JxvKIc-u2oyafmFB_5pdSYwf1i2KCS7yI=.afa41193-a789-4bd8-8b8b-73350cacb50e@github.com>

On Wed, 14 May 2025 07:18:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLogging.hpp line 82:
>> 
>>> 80: //
>>> 81: // [2] When using CDS archives
>>> 82: //     - These logs can be selected ONLY with -Xlog:cds. They are always printed with [cds] decoration
>> 
>> OK, so if I use `-Xlog:all`, what will they be selected as?
>
> `-Xlog:all` will enable all `LogTagSets`. Each `aot_log_xxx()` statement will print exactly one log. When using AOT caches, the log will be printed with `[aot]` decorations. When using CDS archives, the log will be printed with `[cds]` decorations.

Alright, I think we should simplify the comments a bit then. Just 'when using AOT cache, these logs are selected via the aot tag, and not the cds tag. When using CDS, these logs are selected via the cds tag, and not the aot tag.' but with the structure you had. The "ONLY with -Xlog:aot" makes it sound like `-Xlog:all` won't select cds or aot tags anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25136#discussion_r2090483374

From jsikstro at openjdk.org  Thu May 15 08:24:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 15 May 2025 08:24:06 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v3]
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <REGszg1Cx8oLiRhMFpeqlWIt9rK_in37SwhBU_v2Qpw=.c40840ee-0be2-4acc-9e7d-d05ab14942b2@github.com>

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propose we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap in the periodic printing before/after GC invocation(s). The periodic printing is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Flip order of periodic events in hs_err files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25214/files
  - new: https://git.openjdk.org/jdk/pull/25214/files/3a6c6a83..711ce2a2

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

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

PR: https://git.openjdk.org/jdk/pull/25214

From jsikstro at openjdk.org  Thu May 15 08:26:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 15 May 2025 08:26:51 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v2]
In-Reply-To: <tEr9ltXTwUS_VpGxa28ZQDAssyhL22tneOlg4aAGiuM=.76079982-0aed-4c25-ba32-18257e3f39c7@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <tEr9ltXTwUS_VpGxa28ZQDAssyhL22tneOlg4aAGiuM=.76079982-0aed-4c25-ba32-18257e3f39c7@github.com>
Message-ID: <sfwiYPFM9AQIZf5Gl16SRWI28E9HVxxZvSi0fPdEkBw=.5cc16299-b765-4257-a053-08a000dd33b1@github.com>

On Tue, 13 May 2025 16:14:06 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propose we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap in the periodic printing before/after GC invocation(s). The periodic printing is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HeapInfoTest should check that GC.heap_info actually runs

With feedback from @stefank, I've flipped the order of Metaspace Usage and GC Heap Usage in hs_err files so that GC Heap Usage comes first. Example output:

GC Heap Usage History (70 events):
Event: 0,896 {heap Before GC invocations=0 (full 0):
 ZHeap           used 860M, capacity 860M, max capacity 9216M
  Cache          0M (0)
}
...

Metaspace Usage History (70 events):
Event: 0,896 {metaspace Before GC invocations=0 (full 0):
 Metaspace       used 18663K, committed 19008K, reserved 1114112K
  class space    used 1601K, committed 1728K, reserved 1048576K
}
...

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2882994637

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/25122

From duke at openjdk.org  Thu May 15 09:57:18 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 09:57:18 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v4]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <TZPHV4bpAY92nfYXr_Ffve-u3NmzB8MYf5tsw8rCp9Q=.b5d77705-1e1c-4c81-a251-022f27ae5e5d@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused method getDockerVersionStr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/3b18431d..61ca55ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Thu May 15 09:57:19 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 09:57:19 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>
Message-ID: <2ipbr_eKTB9-n_iHSSim1CqnM4thc3Yv6s5XuAvAKQE=.6a26fe01-853e-41fc-9090-182560004dd2@github.com>

On Wed, 14 May 2025 09:41:58 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166:
> 
>> 164:             return null;
>> 165:         }
>> 166:     }
> 
> Do you still need this method?

Removed the method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2090785990

From duke at openjdk.org  Thu May 15 10:03:11 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 10:03:11 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/61ca55ee..b3ccffd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Thu May 15 10:03:11 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 10:03:11 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
Message-ID: <1elyKkFE2sZemPibqVeEswvApPKGWXVqeEMHc4rJpds=.9fff5366-2c8c-48b1-9523-a51b7f4a52ad@github.com>

On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> The change looks good. There might be some issues with container engine version parsing.
> 
> I wrote 2 comments. but cold not post them. They are in "pending" state.
> Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

@Domest0s I have tested against both docker and podman version and it was able to parse
for eg `docker version 20.10.0` and `podman version 4.9.4-rhel`

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

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2883250455

From sspitsyn at openjdk.org  Thu May 15 11:16:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 May 2025 11:16:54 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v7]
In-Reply-To: <6RBr-oNS5owKpLziXGg92SH1ZCJMZl3ePH2GF-RbGsc=.d6ffed1a-d9e5-4fcf-9160-f506e5b52dbc@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <6RBr-oNS5owKpLziXGg92SH1ZCJMZl3ePH2GF-RbGsc=.d6ffed1a-d9e5-4fcf-9160-f506e5b52dbc@github.com>
Message-ID: <IWN1Mh2MW2VvHEz1SYdYRafdPe2HUu8hUuBmRVAyY6A=.f7b8b7a0-0385-422a-94ee-0250074bdd11@github.com>

On Wed, 14 May 2025 17:42:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken copyright

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2843290783

From sspitsyn at openjdk.org  Thu May 15 11:17:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 May 2025 11:17:59 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
 <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
Message-ID: <jvO31NlAF_9LfydEOQTd-uzapHVonZEvZcFGAasVTgw=.05d5a153-a478-478c-a229-ae04a485531b@github.com>

On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2843294716

From jsikstro at openjdk.org  Thu May 15 11:47:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 15 May 2025 11:47:07 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Update new order in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25214/files
  - new: https://git.openjdk.org/jdk/pull/25214/files/711ce2a2..689a2230

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=02-03

  Stats: 6 lines in 2 files changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25214/head:pull/25214

PR: https://git.openjdk.org/jdk/pull/25214

From rvansa at openjdk.org  Thu May 15 12:27:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 15 May 2025 12:27:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v4]
In-Reply-To: <puTVwlJMNUEAZ9b51LZPeCe0MsCYsg3eEADp987VC8A=.673dc352-b4b2-4ad6-a537-eef93eb8ed9b@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <79Pko1ZqYtuWaLO_NaMrTegVy7b1G6Ao0PZ48qZluoE=.adeaceae-d2f1-4b35-8f9f-a450919a37bb@github.com>
 <puTVwlJMNUEAZ9b51LZPeCe0MsCYsg3eEADp987VC8A=.673dc352-b4b2-4ad6-a537-eef93eb8ed9b@github.com>
Message-ID: <FQufRj0aBP8QCy5RcQbaj0qWHdXfX5usl6Bt7tt1D9k=.6bf9b5d8-ba61-4347-b18c-ee7f4ef32f48@github.com>

On Mon, 12 May 2025 16:45:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move constant to static final var
>
> Changes requested by cjplummer (Reviewer).

@plummercj When I've applied your suggestion to load the constant, I've triggered an error in some tests on MacOS and Windows (not sure if this is specific to those platforms or if this is only about timing...). Do you think this is still viable?

java.lang.RuntimeException: VM.initialize() was not yet called
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.getVM(VM.java:576)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Field.<clinit>(Field.java:36)

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2883635142

From mseledtsov at openjdk.org  Thu May 15 15:48:52 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 15 May 2025 15:48:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
Message-ID: <tHaAkBxd-wA6r3knfmJK7GBq4azS5MjY8-AWl8ALNBU=.ed8f12f6-7b33-47b1-88e9-7ab98b20ba7c@github.com>

On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import

Marked as reviewed by mseledtsov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844233145

From lmesnik at openjdk.org  Thu May 15 16:29:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 May 2025 16:29:13 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
Message-ID: <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>

On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73:

> 71:             return;
> 72:         }
> 73:         if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) {

Better to replace this with 
`isContainerVersionSupported()`
...
and implement all logic in the the ContainerRuntimeVersionTestUtils

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38:

> 36:     private final int micro;
> 37:     private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0);
> 38:     public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0);

Please add comment about meaning of the version or even better rename 
DOCKER_MINIMAL_SUPPORTED_VERSION = ....

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53:

> 51:         } else if (this.major < other.major) {
> 52:             return -1;
> 53:         } else { // equal major

no need to add `else {` here

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58:

> 56:             } else if (this.minor < other.minor) {
> 57:                 return -1;
> 58:             } else { // equal majors and minors

no need to add `else {` here

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81:

> 79:         } catch (Exception e) {
> 80:             System.out.println("Failed to parse container runtime version: " + version);
> 81:             return DEFAULT;

Any reason to don't fail here?

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94:

> 92:         } catch (Exception e) {
> 93:             System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null");
> 94:             return null;

Any reason to don't fail here?

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

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844326936
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091561369
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091564985
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555059
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555200
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091567641
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091566692

From lmesnik at openjdk.org  Thu May 15 16:34:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 May 2025 16:34:02 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
 <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
Message-ID: <KbGp7OQcSBVNERym9pVfavJecZtrHActGQZRS2iz59c=.87c1048e-8b2b-4dc1-aab0-74dd73cf63ee@github.com>

On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Test looks good

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2844363722

From amenkov at openjdk.org  Thu May 15 20:43:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 15 May 2025 20:43:02 GMT
Subject: Integrated: 8356177: Regression after JDK-8352180
In-Reply-To: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
Message-ID: <2ojKlB9PaFKSrAijSrKsQteEa_KULOmYem27EGDssJE=.dad1f09f-4b67-4451-b8a0-e95cf9737263@github.com>

On Tue, 13 May 2025 20:49:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: fe790cb3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe790cb319243dc381f5f12f9010e33681ecb17a
Stats:     84 lines in 2 files changed: 80 ins; 0 del; 4 mod

8356177: Regression after JDK-8352180

Reviewed-by: sspitsyn, cjplummer, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/25219

From cjplummer at openjdk.org  Thu May 15 22:49:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 May 2025 22:49:45 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
Message-ID: <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>

> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
> 
> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
> 
> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix comment to reference threadByFieldName()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25190/files
  - new: https://git.openjdk.org/jdk/pull/25190/files/6ab78d6d..f5d18f8a

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

  Stats: 26 lines in 25 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25190/head:pull/25190

PR: https://git.openjdk.org/jdk/pull/25190

From cjplummer at openjdk.org  Thu May 15 23:00:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 May 2025 23:00:51 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <RT46gRixjj1yb40nITwtPjS7qZrYtPSswQA0s_luIKs=.f1e6a48c-5b49-4ffa-9daa-0dae67fc5028@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
 <8mn28z_GYTH9IwYstb1uIAMW9OvQXtb3_FRzsWyYYCU=.0b647309-12ea-4b92-b659-1c04d10feb92@github.com>
 <yL3Vu5xGUPvBAJixdkQiRPOfVeuo_9O_2iCxjgDFFrM=.6b38b60b-f58d-496d-94de-d8bdcf9a0986@github.com>
 <RT46gRixjj1yb40nITwtPjS7qZrYtPSswQA0s_luIKs=.f1e6a48c-5b49-4ffa-9daa-0dae67fc5028@github.com>
Message-ID: <U7mCxoJj8-d3Uv62rXnGwNCHiq65dkulmfm-zLdN6kc=.9e113baf-f534-4e87-98f4-a6fb8ebc681e@github.com>

On Wed, 14 May 2025 19:27:30 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Actually debuggee.classByName() returns null if the class is not found, and callers typically do not check for this, which results in an NPE later on. debuggee.classByName() can also throw an exception if it discovers something like multiple matches for the class name.
>> 
>> I'm not so sure the added error handling is of any real benefit here, and just adds to the already overdone error handling. Exceptions seem to properly result in a quick exit, and in fact it is the error handling that can result in not exiting quickly due to trying to sync with the debuggee. I'd like to request not having to add additional checks when calling debuggee.classByName()
>
>> I'm not so sure the added error handling is of any real benefit here, and just adds to the already overdone error handling. Exceptions seem to properly result in a quick exit, and in fact it is the error handling that can result in not exiting quickly due to trying to sync with the debuggee.
> 
> My concern is about debugee process. I'm not sure all tests have a debugees which exits shortly after the debugger disconnects. So we can get stale debuggee processes on test failures

After some private discussion, Alex and I have agreed that the classByName() calls are ok as-is. They would need both null checking and exception checking, but this is unnecessary because either condition results in an exception that will result in the test existing quickly and gracefully, and with a proper exception backtrace (I tested these bad classByName() results with all tests in this PR). Also, there are many pre-existing cases of tests either not checking for null or not checking for an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2092074462

From cjplummer at openjdk.org  Thu May 15 23:11:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 May 2025 23:11:51 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
Message-ID: <Px07KhBbrKQoiDSAFaw7YB67g-a7hIh3Yj-X78otFZA=.efc76e5e-0916-41e8-8b0b-4e84a9ec05d4@github.com>

On Tue, 13 May 2025 22:11:25 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comment to reference threadByFieldName()
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 119:
> 
>> 117: 
>> 118:         // debuggee main class
>> 119:         mainClass = debuggee.classByName(DEBUGGEE_CLASS);
> 
> Maybe just move this into `try` and replace `debuggee.threadByFieldName` with `debuggee.threadByFieldNameOrThrow`?

@alexmenkov It looks like this could be done in almost every test in this PR. In some the `try` just needs to move about 8 lines up, but in others it's more like 20. There will be a lot of indentation diffs. Do you still want to see this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2092082041

From cjplummer at openjdk.org  Fri May 16 02:55:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 02:55:52 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <Px07KhBbrKQoiDSAFaw7YB67g-a7hIh3Yj-X78otFZA=.efc76e5e-0916-41e8-8b0b-4e84a9ec05d4@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
 <Px07KhBbrKQoiDSAFaw7YB67g-a7hIh3Yj-X78otFZA=.efc76e5e-0916-41e8-8b0b-4e84a9ec05d4@github.com>
Message-ID: <B_9bgckkNQgVnIJhMZxUx50AfJ8RJJWCF4OO1hbhQ6I=.dc3f2cbb-97c3-4246-839c-014d616cb36c@github.com>

On Thu, 15 May 2025 23:08:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 119:
>> 
>>> 117: 
>>> 118:         // debuggee main class
>>> 119:         mainClass = debuggee.classByName(DEBUGGEE_CLASS);
>> 
>> Maybe just move this into `try` and replace `debuggee.threadByFieldName` with `debuggee.threadByFieldNameOrThrow`?
>
> @alexmenkov It looks like this could be done in almost every test in this PR. In some the `try` just needs to move about 8 lines up, but in others it's more like 20. There will be a lot of indentation diffs. Do you still want to see this change?

It looks like there were some changes in part 3 that could also benefit from this. Perhaps this would be better off done in a followup PR. It will keep this PR easier to review, will make moving the `try` easier to review, and will pickup some additional tests that could use this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2092235925

From iklam at openjdk.org  Fri May 16 04:38:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 16 May 2025 04:38:47 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v9]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <sSG5naxn2C6qDxZeeWAfEjDoFggZBBcwUbjb9AYDRfY=.434d9f49-5c83-49fa-920f-02c373fbe161@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @jdksjolen review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/2a4355f8..78a79ac4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/25136

From ayang at openjdk.org  Fri May 16 08:36:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 16 May 2025 08:36:22 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/36583a8f..dc9eb4f1

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

  Stats: 2851 lines in 90 files changed: 2471 ins; 182 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Fri May 16 08:36:25 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 16 May 2025 08:36:25 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <ZqppdasCApR5hBmr8BkQeF2eQgd4G6QheLttH4Xu1dU=.3aee27ee-7335-42c5-98df-0c4d1e3491f6@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <ZqppdasCApR5hBmr8BkQeF2eQgd4G6QheLttH4Xu1dU=.3aee27ee-7335-42c5-98df-0c4d1e3491f6@github.com>
Message-ID: <xSjxUtEhsfM7OaN6ujWp8Cu2-8SnsZumcin9NbWf46k=.b9134616-84e9-407e-b02f-56d64cbe2686@github.com>

On Sun, 11 May 2025 14:24:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:
> 
>> 341:       if (is_gc_overhead_limit_reached()) {
>> 342:         return nullptr;
>> 343:       }
> 
> It seems the parameter `gc_overhead_limit_was_exceeded` and the field `MemAllocator::Allocation::_overhead_limit_exceeded` are not used by all GCs now. Should we keep the parameter and set it as `true` under the condition `is_gc_overhead_limit_reached()`? For example:
> 
> 
>       if (op.prologue_succeeded()) {
>         assert(is_in_or_null(op.result()), "result not in heap");
>         if (is_gc_overhead_limit_reached()) {
>           *gc_overhead_limit_was_exceeded = true;
>           return nullptr;
>         }
>         return op.result();
>       }
> 
> 
> Or we should remove the parameter and the field in another PR.

Since this is not implemented by any other GCs, I think it's best to remove it in a follow-up PR.

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 825:
> 
>> 823:   // If MinHeapFreeRatio is at its default value; shrink cautiously. Otherwise, users expect prompt shrinking.
>> 824:   if (FLAG_IS_DEFAULT(MinHeapFreeRatio) && MinHeapFreeRatio == 0) {
>> 825:     if (desired_capacity < current_capacity) {
> 
> I think curiously a lot about the condition `MinHeapFreeRatio == 0` and then I find the following code in `parallelArguments.cpp`. May it be better to use `UseAdaptiveSizePolicy && FLAG_IS_DEFAULT(MinHeapFreeRatio)` here instead of `FLAG_IS_DEFAULT(MinHeapFreeRatio) && MinHeapFreeRatio == 0`?
> 
> 
>   if (UseAdaptiveSizePolicy) {
>     // We don't want to limit adaptive heap sizing's freedom to adjust the heap
>     // unless the user actually sets these flags.
>     if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) {
>       FLAG_SET_DEFAULT(MinHeapFreeRatio, 0);
>     }
>     if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) {
>       FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100);
>     }
>   }

This method is invoked only when `UseAdaptiveSizePolicy == true`. Removed `MinHeapFreeRatio == 0`.

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 862:
> 
>> 860:   resize_old_gen_after_full_gc();
>> 861:   young_gen()->resize_after_full_gc();
>> 862: }
> 
> The `PSYoungGen` has its methods `resize_after_full_gc` and `resize_after_young_gc`. I think such design is good. What about moving the method `resize_old_gen_after_full_gc` (and the related method `calculate_desired_old_gen_capacity`) to `PSOldGen` and renaming it as `resize_after_full_gc`?

`resize_old_gen_after_full_gc` contains some logic around `MinHeapFreeRatio` that makes it unsuitable to be placed inside old-gen, IMO. Given there is on-going work/discussion on removing/limiting MinHeapFreeRatio in https://bugs.openjdk.org/browse/JDK-8353716 in G1, I think we don't need to optimize for the structure too much, as it will probably be changed soon.

> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 45:
> 
>> 43:      _avg_promoted(new AdaptivePaddedNoZeroDevAverage(AdaptiveSizePolicyWeight, PromotedPadding)),
>> 44:      _space_alignment(space_alignment),
>> 45:      _young_gen_size_increment_supplement(YoungGenerationSizeSupplement) {}
> 
> Typos in `gc_globals.hpp`(shown below): `YoungedGenerationSizeIncrement` and `YoungedGenerationSizeSupplement`. It should be fixed in another PR.
> 
>   product(uint, YoungGenerationSizeIncrement, 20,                           \
>           "Adaptive size percentage change in young generation")            \
>           range(0, 100)                                                     \
>                                                                             \
>   product(uint, YoungGenerationSizeSupplement, 80,                          \
>           "Supplement to YoungedGenerationSizeIncrement used at startup")   \ // <--- here
>           range(0, 100)                                                     \
>                                                                             \
>   product(uintx, YoungGenerationSizeSupplementDecay, 8,                     \
>           "Decay factor to YoungedGenerationSizeSupplement")                \ // <--- here
>           range(1, max_uintx)                                               \

Filed: https://bugs.openjdk.org/browse/JDK-8357109

> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1104:
> 
>> 1102:     heap->post_full_gc_dump(&_gc_timer);
>> 1103: 
>> 1104:     size_policy->record_gc_pause_end_instant();
> 
> What about moving this invocation into `major_collection_end`? Just like the `record_gc_pause_start_instant` and `major_collection_begin`.

This method should be called at the end of gc-pause to better reflect the actual mutator-running/paused time. OTOH, we also adaptive-resizing using gc-pause-time, so there is a circular dependency. Therefore, I invoke `major_collection_end` before adaptive-resizing as a compromise. This issue is more evident for young-gc, as young-gc is usually much shorter; see the comment next to `size_policy->minor_collection_end`.

> src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 179:
> 
>> 177:     _gc_distance_timer.reset();
>> 178:     _gc_distance_timer.start();
>> 179:   }
> 
> The method name `record_gc_pause_end_instant` is about `gc pause`, but the code is about `gc distance`. May we need a clearer name?

In stw-gc, when a gc-pause ends, mutators start running, so the distance btw two consecutive gc-pauses start to tick. This looks quite clear to me, but I am ofc biased. What names do you suggest?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092493546
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092594791
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092589932
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092502996
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092520272
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2092526857

From sspitsyn at openjdk.org  Fri May 16 18:23:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:23:55 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
Message-ID: <bhYGg2xGqjYZKLLXmZQsDs6z9w_TUSXBvfMaFbSCygY=.f2ff43c5-e2e8-4ffd-8d7a-ce5c0997ead4@github.com>

On Thu, 15 May 2025 22:49:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
>> 
>> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
>> 
>> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment to reference threadByFieldName()

I also noticed this issue with exceptions but waited you to sort this out with Alex first.
I'm okay to separate it from this PR. Current PR looks good then.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25190#pullrequestreview-2847347180

From amenkov at openjdk.org  Fri May 16 18:43:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 16 May 2025 18:43:57 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
Message-ID: <4RubxXxdNKu4ZDV-aeXlizFTIR_Kw8oXFwggLSA82t8=.5adc9c49-90ab-4f35-8642-a1d476d463f9@github.com>

On Thu, 15 May 2025 22:49:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
>> 
>> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
>> 
>> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment to reference threadByFieldName()

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25190#pullrequestreview-2847383505

From sspitsyn at openjdk.org  Fri May 16 18:45:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:45:55 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.cpp line 399:

> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
> 398:   size_t interval = static_cast<size_t>(result);
> 399:   _sample_threshold = interval;

Nit: The line 399 is not needed as the value is reset at 400.

src/hotspot/share/runtime/threadHeapSampler.hpp line 89:

> 87: 
> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
> 89:     pick_next_sample();

The old identifier is used: _bytes_until_sample.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093526227
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093523489

From sspitsyn at openjdk.org  Fri May 16 18:50:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:50:52 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <BVgcUFxoNDseh6iWTfm2dcFL36o4km8ehX1YLoRBLRM=.40898d89-05e3-48d8-a646-e2eccbceb9a2@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.hpp line 82:

> 80:       _tlab_top_at_sample_start(nullptr),
> 81:       _accumulated_tlab_bytes_since_sample(0),
> 82:       _accumulated_outside_tlab_bytes_since_sample(0) {

Nit: Would it make sense to initialize `_sample_threshold` as well to make it consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093531027

From sspitsyn at openjdk.org  Fri May 16 18:57:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:57:58 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.hpp line 92:

> 90:   }
> 91: 
> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {

Nit: I wonder if we can make names shorter with replacing:
  `bytes_since_last_sample` => `unsampled_bytes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093538501

From cjplummer at openjdk.org  Fri May 16 20:10:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 20:10:52 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <B_9bgckkNQgVnIJhMZxUx50AfJ8RJJWCF4OO1hbhQ6I=.dc3f2cbb-97c3-4246-839c-014d616cb36c@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <zR7PkkIBWk1QPD2M_c1YzO0yJInw7P1DDJnoLD7SNAk=.3ece69b5-fe08-4490-b81e-414ab20da27f@github.com>
 <Px07KhBbrKQoiDSAFaw7YB67g-a7hIh3Yj-X78otFZA=.efc76e5e-0916-41e8-8b0b-4e84a9ec05d4@github.com>
 <B_9bgckkNQgVnIJhMZxUx50AfJ8RJJWCF4OO1hbhQ6I=.dc3f2cbb-97c3-4246-839c-014d616cb36c@github.com>
Message-ID: <FLfhc7ICLYcIttrZ0_4qD6kcn4i7ZTl_TUQd5a9H_QY=.e64789f6-b65f-48d0-b05a-58164a0a44de@github.com>

On Fri, 16 May 2025 02:52:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @alexmenkov It looks like this could be done in almost every test in this PR. In some the `try` just needs to move about 8 lines up, but in others it's more like 20. There will be a lot of indentation diffs. Do you still want to see this change?
>
> It looks like there were some changes in part 3 that could also benefit from this. Perhaps this would be better off done in a followup PR. It will keep this PR easier to review, will make moving the `try` easier to review, and will pickup some additional tests that could use this.

I filed [JDK-8357172](https://bugs.openjdk.org/browse/JDK-8357172)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25190#discussion_r2093619239

From ihse at openjdk.org  Fri May 16 20:26:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 May 2025 20:26:56 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <hpXaVehyPOVYVXO8qnUxTAVKQ50NSwgUj5JjPPcs8_s=.e45fe420-1d0a-451c-a016-8a7102d84834@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

I think so.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2887613040

From cjplummer at openjdk.org  Fri May 16 20:47:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 20:47:57 GMT
Subject: RFR: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4 [v2]
In-Reply-To: <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
 <14E8isqnBhEozMKTGjVUByYO4mzUlB6Huw5Hwd23YzI=.69b31bb7-c6c5-4cfa-bc26-7a727faafb8f@github.com>
Message-ID: <28VInPUyhxl-l9mhXD9cYM05b0SH8LIYMffHtANEIAs=.3cb880f0-5bef-4929-a5db-651bb26d297b@github.com>

On Thu, 15 May 2025 22:49:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
>> 
>> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
>> 
>> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment to reference threadByFieldName()

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25190#issuecomment-2887644214

From cjplummer at openjdk.org  Fri May 16 20:47:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 20:47:58 GMT
Subject: Integrated: 8356811: Some nsk/jdi tests can fetch ThreadReference from
 static field in the debuggee: part 4
In-Reply-To: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
References: <G0KMhVFOLNT-BXQHTH-UOJe2F5S6GosF4TsvTBDDCR4=.c28749c6-204e-4af2-bf0f-320a3b138526@github.com>
Message-ID: <v3e3ur956xjPwwK4tKszR2GMLMX3AmaR-Hdh-FQCw94=.a6ba4fae-99cc-4d05-8c9c-fe85956c29fa@github.com>

On Mon, 12 May 2025 19:35:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This batch of changes mostly concerns the remaining uses of threadByName() and converting them to use threadByFieldNameOrThrow() or the new threadByFieldName(). The latter is used if the caller has code to handle a null result. The former is when an exception is needed to get the test to terminate properly. I did fix a few long standing cases where threadyByName() was being called and not checking the result. These call sites now use threadByFieldNameOrThrow() instead of threadByFieldName().
> 
> Note there is a minor semantic change in doing this. threadByName() has some extra code to check that the named thread is only found once, and will throw an exception if it is. I think this was just some extra checking that was being done during test development, and is not needed for proper test execution. I've run all the tests without this check and they still pass. I plan on removing this check at some point. 
> 
> Tested by running all tier5 svc tests, which includes the nsk/jdi tests. Also ran tier1 and ran locally.

This pull request has now been integrated.

Changeset: 10258dc5
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10258dc56eb7d5d99ca8ed2579e871de91c74769
Stats:     612 lines in 74 files changed: 253 ins; 90 del; 269 mod

8356811: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 4

Reviewed-by: sspitsyn, amenkov

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

PR: https://git.openjdk.org/jdk/pull/25190

From matsaave at openjdk.org  Fri May 16 20:54:54 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 16 May 2025 20:54:54 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v9]
In-Reply-To: <sSG5naxn2C6qDxZeeWAfEjDoFggZBBcwUbjb9AYDRfY=.434d9f49-5c83-49fa-920f-02c373fbe161@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <sSG5naxn2C6qDxZeeWAfEjDoFggZBBcwUbjb9AYDRfY=.434d9f49-5c83-49fa-920f-02c373fbe161@github.com>
Message-ID: <Hrk8Agf0rmok96Dms8zS-WDOESiEIzdrcBnmm2j4_O8=.b26d3689-4a53-4800-b302-0c51cdfe3a82@github.com>

On Fri, 16 May 2025 04:38:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @jdksjolen review comments

Changes make sense, looks good!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2847605104

From cjplummer at openjdk.org  Fri May 16 20:57:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 20:57:38 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v8]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into 8353955_nsk_jdk_includevirtualthreads
 - fix broken copyright
 - remove mistaken edit
 - remove mistaken edit
 - Remove mistakenly added file.
 - update the set of tests that need to be run with -includevirtualthreads
 - No longer any need for -includevirtualthreads with these tests.
 - Add support for -includevirtualthreads test argument.
 - get rid of commented out change
 - Don't always use includevirtualthreads=y

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

Changes: https://git.openjdk.org/jdk/pull/24606/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=07
  Stats: 47 lines in 25 files changed: 37 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From coleenp at openjdk.org  Fri May 16 21:04:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 16 May 2025 21:04:59 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v4]
In-Reply-To: <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
Message-ID: <GSuHpw4QtZLATztJ6eSnp_QcECEm6fLFokZfYPJSbTI=.47c77295-d90e-49d1-aafa-a567297fe3c4@github.com>

On Fri, 9 May 2025 22:34:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move other tier 4,5, etc tests to not use ClassReader
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Use classfile api instead of javac setting version
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - 8356548: Avoid using ASM to parse latest class files in tests

The runtime test that I know looks good.  Ask @iwanowww and @sspitsyn about the compiler and redefinition tests.

test/hotspot/jtreg/runtime/MirrorFrame/Asmator.java line 38:

> 36:                     public void atStart(CodeBuilder builder) {
> 37:                         // make receiver go dead!
> 38:                         builder.aconst_null().astore(0);

This looks much better.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-2847613695
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2093670551

From cjplummer at openjdk.org  Fri May 16 22:11:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 May 2025 22:11:57 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v8]
In-Reply-To: <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>
Message-ID: <5dZ0ONdQXNsMajYy3p1QL41zjPZKtH3p_cDio_aEfVw=.5683a39d-513e-4c4a-8cb4-7e3caa40b09b@github.com>

On Fri, 16 May 2025 20:57:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into 8353955_nsk_jdk_includevirtualthreads
>  - fix broken copyright
>  - remove mistaken edit
>  - remove mistaken edit
>  - Remove mistakenly added file.
>  - update the set of tests that need to be run with -includevirtualthreads
>  - No longer any need for -includevirtualthreads with these tests.
>  - Add support for -includevirtualthreads test argument.
>  - get rid of commented out change
>  - Don't always use includevirtualthreads=y

I finished merging with the dependent PRs and have teste. All tests seem to be passing now. I think this PR is now ready for final review and integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2887756499

From jrose at openjdk.org  Fri May 16 23:53:53 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 16 May 2025 23:53:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
Message-ID: <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>

On Wed, 14 May 2025 12:46:41 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Revert change in array.hpp
>  - Revert changes in VerifyRawIndexesTest
>  - Improve FieldInfo::print
>  - Load constant for SORTED_FIELD_TABLE_THRESHOLD
>  - Replace JumpTable with SortedFieldTable

This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.

I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.

It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.

It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.

BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.

The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.

One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.

I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2887857145

From amenkov at openjdk.org  Sat May 17 00:18:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 17 May 2025 00:18:55 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v8]
In-Reply-To: <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>
Message-ID: <XawF-ksyKvZnGL9bLs1zLa4CidjQyQFTC3pjc3z9RgU=.67ab21f5-5dc5-4969-9b12-af91bf6e06bd@github.com>

On Fri, 16 May 2025 20:57:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into 8353955_nsk_jdk_includevirtualthreads
>  - fix broken copyright
>  - remove mistaken edit
>  - remove mistaken edit
>  - Remove mistakenly added file.
>  - update the set of tests that need to be run with -includevirtualthreads
>  - No longer any need for -includevirtualthreads with these tests.
>  - Add support for -includevirtualthreads test argument.
>  - get rid of commented out change
>  - Don't always use includevirtualthreads=y

Looks good.
Many files still need copyright update.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2887876379

From cjplummer at openjdk.org  Sat May 17 05:04:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 17 May 2025 05:04:39 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v9]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <VCwfxQQmdmNx56-n-LtSPnTsj95gjz-B5HmsecOnGwQ=.e84e134a-d1e0-40bd-ba06-2b40d78ec8e7@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/4889f503..b5e25f01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=07-08

  Stats: 41 lines in 41 files changed: 0 ins; 0 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From cjplummer at openjdk.org  Sat May 17 05:04:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 17 May 2025 05:04:39 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v8]
In-Reply-To: <XawF-ksyKvZnGL9bLs1zLa4CidjQyQFTC3pjc3z9RgU=.67ab21f5-5dc5-4969-9b12-af91bf6e06bd@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <TI2WiAo4mB89kICMVz7xwbQLgby2S7tYYG259AwHBf4=.a4f3b886-bba7-407f-98a8-db8ae95f9f1a@github.com>
 <XawF-ksyKvZnGL9bLs1zLa4CidjQyQFTC3pjc3z9RgU=.67ab21f5-5dc5-4969-9b12-af91bf6e06bd@github.com>
Message-ID: <NPRPstLHgdBYnE29-n0ykSxloEBYxVw7egOSNREsD90=.13199214-7145-4137-94c7-4b583b0219c5@github.com>

On Sat, 17 May 2025 00:16:18 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Many files still need copyright update.

I forgot about that. They are updated now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2888082943

From zgu at openjdk.org  Sun May 18 00:28:56 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 18 May 2025 00:28:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
Message-ID: <-k-DamMcH1pZ4vSAkWjhlM5PD777oPKlkrX0JK2SsSk=.de6913a9-3e2f-4cc5-bc53-e251c82ed78d@github.com>

On Fri, 16 May 2025 08:36:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - pgc-size-policy

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 51:

> 49: #include "oops/oop.inline.hpp"
> 50: #include "runtime/cpuTimeCounters.hpp"
> 51: #include "runtime/globals_extension.hpp"

Don't see why it is needed.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 404:

> 402:     collect_at_safepoint(!should_run_young_gc);
> 403: 
> 404:     if (is_gc_overhead_limit_reached()) {

Maybe want to adopt current algorithm, start to clear soft references when approaching gc overhead limit?
Running a full gc and clearing all soft references without retrying allocation and throws OOM, seems a bit harsh.

People still use soft references for caches, reclaim soft references could potentially free large amount of memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2087170321
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2087828140

From gli at openjdk.org  Sun May 18 12:20:51 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 12:20:51 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <xSjxUtEhsfM7OaN6ujWp8Cu2-8SnsZumcin9NbWf46k=.b9134616-84e9-407e-b02f-56d64cbe2686@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <ZqppdasCApR5hBmr8BkQeF2eQgd4G6QheLttH4Xu1dU=.3aee27ee-7335-42c5-98df-0c4d1e3491f6@github.com>
 <xSjxUtEhsfM7OaN6ujWp8Cu2-8SnsZumcin9NbWf46k=.b9134616-84e9-407e-b02f-56d64cbe2686@github.com>
Message-ID: <VEV1hQyTpLRmt8sVjOgwkmT2DAjcc2XEFr1lwjQkSSM=.624be2ac-590c-49af-8946-188f58d03b9a@github.com>

On Fri, 16 May 2025 07:27:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:
>> 
>>> 341:       if (is_gc_overhead_limit_reached()) {
>>> 342:         return nullptr;
>>> 343:       }
>> 
>> It seems the parameter `gc_overhead_limit_was_exceeded` and the field `MemAllocator::Allocation::_overhead_limit_exceeded` are not used by all GCs now. Should we keep the parameter and set it as `true` under the condition `is_gc_overhead_limit_reached()`? For example:
>> 
>> 
>>       if (op.prologue_succeeded()) {
>>         assert(is_in_or_null(op.result()), "result not in heap");
>>         if (is_gc_overhead_limit_reached()) {
>>           *gc_overhead_limit_was_exceeded = true;
>>           return nullptr;
>>         }
>>         return op.result();
>>       }
>> 
>> 
>> Or we should remove the parameter and the field in another PR.
>
> Since this is not implemented by any other GCs, I think it's best to remove it in a follow-up PR.

Filed https://bugs.openjdk.org/browse/JDK-8357188

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 862:
>> 
>>> 860:   resize_old_gen_after_full_gc();
>>> 861:   young_gen()->resize_after_full_gc();
>>> 862: }
>> 
>> The `PSYoungGen` has its methods `resize_after_full_gc` and `resize_after_young_gc`. I think such design is good. What about moving the method `resize_old_gen_after_full_gc` (and the related method `calculate_desired_old_gen_capacity`) to `PSOldGen` and renaming it as `resize_after_full_gc`?
>
> `resize_old_gen_after_full_gc` contains some logic around `MinHeapFreeRatio` that makes it unsuitable to be placed inside old-gen, IMO. Given there is on-going work/discussion on removing/limiting MinHeapFreeRatio in https://bugs.openjdk.org/browse/JDK-8353716 in G1, I think we don't need to optimize for the structure too much, as it will probably be changed soon.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094507209
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094507227

From gli at openjdk.org  Sun May 18 12:45:58 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 12:45:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <xSjxUtEhsfM7OaN6ujWp8Cu2-8SnsZumcin9NbWf46k=.b9134616-84e9-407e-b02f-56d64cbe2686@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <ZqppdasCApR5hBmr8BkQeF2eQgd4G6QheLttH4Xu1dU=.3aee27ee-7335-42c5-98df-0c4d1e3491f6@github.com>
 <xSjxUtEhsfM7OaN6ujWp8Cu2-8SnsZumcin9NbWf46k=.b9134616-84e9-407e-b02f-56d64cbe2686@github.com>
Message-ID: <e40Iw1YxBGqjQ4LuFdv5Z96t1ep5ZazkTls0Y62SLFs=.1b00ef38-2ad6-4617-a279-a88d69e41ee7@github.com>

On Fri, 16 May 2025 07:50:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 179:
>> 
>>> 177:     _gc_distance_timer.reset();
>>> 178:     _gc_distance_timer.start();
>>> 179:   }
>> 
>> The method name `record_gc_pause_end_instant` is about `gc pause`, but the code is about `gc distance`. May we need a clearer name?
>
> In stw-gc, when a gc-pause ends, mutators start running, so the distance btw two consecutive gc-pauses start to tick. This looks quite clear to me, but I am ofc biased. What names do you suggest?

I don't have a better name now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094513461

From ayang at openjdk.org  Sun May 18 15:20:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 18 May 2025 15:20:50 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/dc9eb4f1..a8d14931

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

  Stats: 50640 lines in 1539 files changed: 24057 ins; 18482 del; 8101 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Sun May 18 15:25:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 18 May 2025 15:25:00 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <-k-DamMcH1pZ4vSAkWjhlM5PD777oPKlkrX0JK2SsSk=.de6913a9-3e2f-4cc5-bc53-e251c82ed78d@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
 <-k-DamMcH1pZ4vSAkWjhlM5PD777oPKlkrX0JK2SsSk=.de6913a9-3e2f-4cc5-bc53-e251c82ed78d@github.com>
Message-ID: <hJNvoBbNNpd4REHJsIBqEnvub2hFo6rugJQeHFc1Zno=.1d60da72-8760-48d3-947c-b1c9c8e4a7e6@github.com>

On Tue, 13 May 2025 15:59:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 51:
> 
>> 49: #include "oops/oop.inline.hpp"
>> 50: #include "runtime/cpuTimeCounters.hpp"
>> 51: #include "runtime/globals_extension.hpp"
> 
> Don't see why it is needed.

It's needed for `FLAG_IS_DEFAULT`; got a build error without this include.

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 404:
> 
>> 402:     collect_at_safepoint(!should_run_young_gc);
>> 403: 
>> 404:     if (is_gc_overhead_limit_reached()) {
> 
> Maybe want to adopt current algorithm, start to clear soft references when approaching gc overhead limit?
> Running a full gc and clearing all soft references without retrying allocation and throws OOM, seems a bit harsh.
> 
> People still use soft references for caches, reclaim soft references could potentially free large amount of memory.

Revised a bit; the limitation of what we have on master is that it doesn't detect gc-overhead for young-gcs. If many young-gcs are run, gc-overhead checking should kick in as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094553207
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094554006

From gli at openjdk.org  Sun May 18 18:08:56 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 18:08:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
Message-ID: <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>

On Sun, 18 May 2025 15:20:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - pgc-size-policy

Some more comments.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:

> 341:       if (_gc_overhead_counter >= GCOverheadLimitThreshold) {
> 342:         return nullptr;
> 343:       }

Returning `nullptr` means the `OutOfMemoryException` should be thrown later. Is it good to add a `error` level log here?

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 363:

> 361: }
> 362: 
> 363: bool ParallelScavengeHeap::check_gc_overhead_limit() {

In main-line code, the method `check_gc_overhead_limit` is invoked by `PSScavenge::invoke` and `PSParallelCompact::invoke_no_policy` so that we can do the check after all the GCs. But now you only use `check_gc_overhead_limit` in `ParallelScavengeHeap::satisfy_failed_allocation`. I suspect whether it can check the gc overhead limit accurately.

src/hotspot/share/gc/parallel/psYoungGen.cpp line 268:

> 266:   size_t original_committed_size = virtual_space()->committed_size();
> 267: 
> 268:   while (true) {

The `while` statement only runs once. Maybe we can find a better way to handle such complex conditional flow.

src/hotspot/share/gc/parallel/psYoungGen.cpp line 268:

> 266:   size_t original_committed_size = virtual_space()->committed_size();
> 267: 
> 268:   while (true) {

The `while` statement only runs once. May we find a better way to refactor the code?

src/hotspot/share/gc/parallel/psYoungGen.cpp line 334:

> 332:   assert(from_space()->capacity_in_bytes() == to_space()->capacity_in_bytes(), "inv");
> 333:   const size_t current_survivor_size = from_space()->capacity_in_bytes();
> 334:   assert(max_gen_size() > 2 * current_survivor_size, "inv");

Should this assertion be changed to `assert(max_gen_size() > current_eden_size + 2 * current_survivor_size, "inv");` ?

src/hotspot/share/gc/parallel/psYoungGen.cpp line 379:

> 377:   // We usually resize young-gen only after a successful young-gc. However, in emergency state, we wanna expand young-gen to its max-capacity.
> 378:   // Young-gen should be empty normally after a full-gc.
> 379:   if (eden_space()->is_empty() && to_space()->is_empty()) {

Why don't you test the `from space` here? And actually, if the `eden space` is empty, the `from space` and `to space` are empty too, because the objects are firstly moved to `eden space`. See the method `PSParallelCompact::summary_phase` for more information. So here, you only need to test whether the `eden space` is empty.

src/hotspot/share/gc/parallel/psYoungGen.cpp line 487:

> 485: 
> 486: void PSYoungGen::resize_spaces(size_t requested_eden_size,
> 487:                                size_t requested_survivor_size) {

You remove some `trace` level logs in this method. Please confirm whether it is your intent?

src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 48:

> 46:   // Default: 100ms.
> 47:   static constexpr double MinGCDistanceSecond = 0.100;
> 48:   static_assert(MinGCDistanceSecond >= 0.001, "inv");

The`MinGCDistanceSecond` is just a contant; the static assertion seems unnecessary?

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

Changes requested by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2848994453
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094590507
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094582368
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094559809
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094559817
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094560936
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094567980
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094571784
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094574692

From gli at openjdk.org  Sun May 18 18:08:56 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 18:08:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
Message-ID: <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>

On Sun, 18 May 2025 18:01:44 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:
> 
>> 341:       if (_gc_overhead_counter >= GCOverheadLimitThreshold) {
>> 342:         return nullptr;
>> 343:       }
> 
> Returning `nullptr` means the `OutOfMemoryException` should be thrown later. Is it good to add a `error` level log here?

And notice: we can't identify the `OutOfMemoryException` whether because `gc overhead limit is exceeded`.

As I pointed out before: `the field MemAllocator::Allocation::_overhead_limit_exceeded are not used now`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094591384

From gli at openjdk.org  Sun May 18 18:08:59 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 18:08:59 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
Message-ID: <Iqn9aLoZslR6GspSVdG2t-w4GDStBKIkXSLmtlRw6k0=.77363a98-248f-4229-a3e2-c15c2ac59ad1@github.com>

On Fri, 16 May 2025 08:36:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - pgc-size-policy

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 232:

> 230:     // Major times are too long, so we want less promotion.
> 231:     incr_tenuring_threshold = true;
> 232:   }

You keep the condition `minor_cost > major_cost * _threshold_tolerance_percent` of the previous code. But it will be strange when we only read the new code (in the future). What about removing the condition `minor_cost > major_cost * _threshold_tolerance_percent` and moving the comment `we prefer young-gc over full-gc` to another place?

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 254:

> 252:     // survived is an underestimate
> 253:     _survived_bytes.add(survived + promoted);
> 254:   }

The parameter `is_survivor_overflow` seems unnecessary. When `is_survivor_overflow` is `false`, the `promoted` is `0`. What about using `_survived_bytes.add(survived + promoted)` only and removing parameter `is_survivor_overflow` (and the related conditional code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094533246
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094536061

From gli at openjdk.org  Sun May 18 18:23:53 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 18 May 2025 18:23:53 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
Message-ID: <-yIbScHlkeICVqjP2oPh4DEhknv41XfABxOf6Np7C7I=.17f1ef14-93af-4d4e-8350-2ad7f2e441a1@github.com>

On Sun, 18 May 2025 15:20:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - pgc-size-policy

src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp line 168:

> 166:     gc_overhead_limit_exceeded_counter()->set_value(
> 167:       (jlong) ps_size_policy()->gc_overhead_limit_exceeded());
> 168:   }

The field `GCPolicyCounters::_gc_overhead_limit_exceeded_counter` and the related methods are not used now. It is good to remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094594014

From serb at openjdk.org  Mon May 19 02:24:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 02:24:24 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type
 mismatch during build
Message-ID: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>

This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).

I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.

A proper fix (e.g., explicit type cast) may be introduced later if necessary.

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

Commit messages:
 - 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build

Changes: https://git.openjdk.org/jdk/pull/25293/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357193
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25293/head:pull/25293

PR: https://git.openjdk.org/jdk/pull/25293

From cjplummer at openjdk.org  Mon May 19 03:00:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 19 May 2025 03:00:55 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <EnQTmPG1KmlHjrHKKMWiPQzS9LM84pQQ6OJjdObTtdg=.9101aae6-394c-43a9-96e9-1263fc70fe38@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

Other references to the jvmti version in the debug agent use the result of calling GetVersionNumber(), which provides a jint. These references are otherwise doing the same bit masking and not seeing this warning. Using the compile time JVMTI_VERSION is appropriate for the code in question (it wants the compile time version), and simply casting it to a jint should resolve the warning.

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

PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889473633

From serb at openjdk.org  Mon May 19 05:28:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 05:28:50 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <U1kvIztuzqBy37VwHjY6mEhlZkmd9h613jbg-t2thNw=.e94d457f-ae13-47f7-976d-2c43c3ecd79d@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

Unfortunately it cannot be suppressed by the cast due to bug in [VS2022](https://developercommunity.visualstudio.com/t/warning-C5287:-operands-are-different-e/10877942?space=21&sort=newest&viewtype=all&entry=myfeedback)

I can suppress it by extracting JVMTI_VERSION into local variable similar to how other code looks like:

>     jint version = JVMTI_VERSION;
>     jvmtiCompileTimeMajorVersion  = ( version & JVMTI_VERSION_MASK_MAJOR )
>                                         >> JVMTI_VERSION_SHIFT_MAJOR;
>     jvmtiCompileTimeMinorVersion  = ( version & JVMTI_VERSION_MASK_MINOR )
>                                         >> JVMTI_VERSION_SHIFT_MINOR;
>     jvmtiCompileTimeMicroVersion  = ( version & JVMTI_VERSION_MASK_MICRO )
>                                         >> JVMTI_VERSION_SHIFT_MICRO;

but it might be better just suppress it in the make file?

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

PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889662879

From kbarrett at openjdk.org  Mon May 19 05:39:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 05:39:51 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <kfji5MB9G90Pg8FSenN74XtGNHHq2921JP9ZbHfqams=.6bb05f27-9e6c-46b9-81d6-4908e7bbabd1@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

The various constants involved here are currently defined as enumerators of
(different) unscoped enums. Perhaps they shouldn't be enumerators at all.
https://github.com/openjdk/jdk/blame/9927ec0b91775db342b2bbc1937253325c367a19/doc/hotspot-style.md#L670-L674
Ordinarily I would say these ought to be typed constexprs, probably `jint`
since these seem to be actual Java values. But some of the code involved needs
to be both valid C and valid C++, which makes that noticeably harder.

I'm okay with the proposed warning suppression as a quick fix for a build
failure, but there should be a followup bug to fix it properly.

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

PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889678580

From ayang at openjdk.org  Mon May 19 06:10:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 May 2025 06:10:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v4]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <Z5I9cRTOobwqo-LvhJVT4POex31ro8y6GQS7QvLpAzk=.1469218d-6eec-4ccb-84cc-8f8d8f15ec34@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/a8d14931..e39ece09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=02-03

  Stats: 69 lines in 10 files changed: 46 ins; 15 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Mon May 19 06:10:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 May 2025 06:10:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
Message-ID: <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>

On Sun, 18 May 2025 18:06:15 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 343:
>> 
>>> 341:       if (_gc_overhead_counter >= GCOverheadLimitThreshold) {
>>> 342:         return nullptr;
>>> 343:       }
>> 
>> Returning `nullptr` means the `OutOfMemoryError` will be thrown later. Is it good to add a `error` level log here?
>
> And notice: we can't identify whether the `OutOfMemoryError` is because of `gc overhead limit exceeded`.
> 
> As I pointed out before: `the field MemAllocator::Allocation::_overhead_limit_exceeded are not used now`.

The one inside the safepoint will print sth `log_info(gc)("GCOverheadLimitThreshold ...`. There can be multiple concurrent mutators reaching here; printing here is undesirable.

I don't think throwing OOM, from gc's perspective, is an "error".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094899794

From ayang at openjdk.org  Mon May 19 06:10:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 May 2025 06:10:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
Message-ID: <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>

On Sun, 18 May 2025 17:21:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> so that we can do the check after all the GCs

Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.

 > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.

I believe so.  In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.


  // Ignore explicit GC's.  Exiting here does not set the flag and
  // does not reset the count.
  if (GCCause::is_user_requested_gc(gc_cause) ||
      GCCause::is_serviceability_requested_gc(gc_cause)) {
    return;
  }

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 268:
> 
>> 266:   size_t original_committed_size = virtual_space()->committed_size();
>> 267: 
>> 268:   while (true) {
> 
> The `while` statement only runs once. May we find a better way to refactor the code?

I don't see an easy to re-structure the code while keeping all the relevant logic in the current context. I added some comments; check if it makes the flow easier to follow.

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 334:
> 
>> 332:   assert(from_space()->capacity_in_bytes() == to_space()->capacity_in_bytes(), "inv");
>> 333:   const size_t current_survivor_size = from_space()->capacity_in_bytes();
>> 334:   assert(max_gen_size() > 2 * current_survivor_size, "inv");
> 
> Should this assertion be changed to `assert(max_gen_size() > current_eden_size + 2 * current_survivor_size, "inv");` ?

Revised; needs to be `>=` though.

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 379:
> 
>> 377:   // We usually resize young-gen only after a successful young-gc. However, in emergency state, we wanna expand young-gen to its max-capacity.
>> 378:   // Young-gen should be empty normally after a full-gc.
>> 379:   if (eden_space()->is_empty() && to_space()->is_empty()) {
> 
> Why don't you test the `from space` here? And actually, if the `eden space` is empty, the `from space` and `to space` are empty too, because the objects are firstly moved to `eden space`. See the method `PSParallelCompact::summary_phase` for more information. So here, you only need to test whether the `eden space` is empty.

Added checking for `from_space`.

If all live-objs don't fit in old-gen, leftovers will be kept in its own space.


  // Summarize the remaining spaces in the young gen.  The initial target space
  // is the old gen.  If a space does not fit entirely into the target, then the
  // remainder is compacted into the space itself and that space becomes the new
  // target.

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 487:
> 
>> 485: 
>> 486: void PSYoungGen::resize_spaces(size_t requested_eden_size,
>> 487:                                size_t requested_survivor_size) {
> 
> You remove some `trace` level logs in this method. Please confirm whether it is your intent?

Yes; when testing/developing, I don't find them to be very useful.

> src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp line 48:
> 
>> 46:   // Default: 100ms.
>> 47:   static constexpr double MinGCDistanceSecond = 0.100;
>> 48:   static_assert(MinGCDistanceSecond >= 0.001, "inv");
> 
> The`MinGCDistanceSecond` is just a contant; the static assertion seems unnecessary?

It's more to convey the intend that this number have a lower bound if future changes want to lower it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094893944
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094867831
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094870461
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094882156
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094882750
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094883781

From ayang at openjdk.org  Mon May 19 06:10:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 May 2025 06:10:45 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <Iqn9aLoZslR6GspSVdG2t-w4GDStBKIkXSLmtlRw6k0=.77363a98-248f-4229-a3e2-c15c2ac59ad1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
 <Iqn9aLoZslR6GspSVdG2t-w4GDStBKIkXSLmtlRw6k0=.77363a98-248f-4229-a3e2-c15c2ac59ad1@github.com>
Message-ID: <H2qJqlfNPnNvzAHU4zNiXLe52fhQeYEvjuArrRmZTBY=.6e9501bd-e617-4322-8f9e-02453ec9b7eb@github.com>

On Sun, 18 May 2025 13:53:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 232:
> 
>> 230:     // Major times are too long, so we want less promotion.
>> 231:     incr_tenuring_threshold = true;
>> 232:   }
> 
> You keep the condition `minor_cost > major_cost * _threshold_tolerance_percent` of the previous code. But it will be strange when we only read the new code (in the future). What about removing the condition `minor_cost > major_cost * _threshold_tolerance_percent` and moving the comment `we prefer young-gc over full-gc` to another place?

I keep it this way because I find the structure to be more symmetric, but I don't have a strong opinion on this. If you prefer, I can remove the empty if-branch. (The resulting asm should be identical.)

> When is_survivor_overflow is false, the promoted is 0

That's not true; objs that live long enough will be promoted as well, even when the survivor-space has plenty of free-space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094855103
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094856261

From rvansa at openjdk.org  Mon May 19 07:13:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 19 May 2025 07:13:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
 <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
Message-ID: <9JwcTNlD0TNfdMEt3N2uf0fJoEUWcDpA_h7SdPYqh4g=.f4ce04e2-c879-478f-9dea-542fb8c28814@github.com>

On Fri, 16 May 2025 23:51:39 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Revert change in array.hpp
>>  - Revert changes in VerifyRawIndexesTest
>>  - Improve FieldInfo::print
>>  - Load constant for SORTED_FIELD_TABLE_THRESHOLD
>>  - Replace JumpTable with SortedFieldTable
>
> This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.
> 
> I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.
> 
> It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.
> 
> It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.
> 
> BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.
> 
> The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.
> 
> One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.
> 
> I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.

@rose00 While refactoring might be useful, this PR is trying to address a performance regression (in fact by improving the scenario significantly), and I'd prefer that to land in 25 rather than to delay just for the sake of better 'reusability'. And TBH I don't consider binary search algorithm too difficult to validate.

While a simple cache might be useful, I don't have a good example to validate its usefulness. And turning a read-only scenario into mutating scenario can turn out badly for multithreaded code, as in https://bugs.openjdk.org/browse/JDK-8180450 .

While you suggest 0 byte as synchronization markers, I've tried to synchronize the stream in #24713 and experiments have shown that while it improves things, it was not sufficient in my case. That's why I've abandoned that approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2889870320

From stefank at openjdk.org  Mon May 19 07:16:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 07:16:57 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
Message-ID: <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>

On Fri, 16 May 2025 18:43:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.cpp line 399:
> 
>> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
>> 398:   size_t interval = static_cast<size_t>(result);
>> 399:   _sample_threshold = interval;
> 
> Nit: The line 399 is not needed as the value is reset at 400.

Nice catch. This is debugging code from the early stage of this patch. It set up a consistent state to make it easier to get consistent data from the test runs. This also means that we need to respin our testing to make sure that the randomization doesn't trigger anything that we didn't catch with the fixed _sample_threshold.

> src/hotspot/share/runtime/threadHeapSampler.hpp line 82:
> 
>> 80:       _tlab_top_at_sample_start(nullptr),
>> 81:       _accumulated_tlab_bytes_since_sample(0),
>> 82:       _accumulated_outside_tlab_bytes_since_sample(0) {
> 
> Nit: Would it make sense to initialize `_sample_threshold` as well to make it consistent?

To me it makes sense. I didn't do it here because it gets initialized further down and I didn't want reviewers to get hung up on that change. But I'll take this as a go-ahead to make that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2094996935
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095001254

From stefank at openjdk.org  Mon May 19 07:24:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 07:24:56 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
Message-ID: <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>

On Fri, 16 May 2025 18:54:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.hpp line 92:
> 
>> 90:   }
>> 91: 
>> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {
> 
> Nit: I wonder if we can make names shorter with replacing:
>   `bytes_since_last_sample` => `unsampled_bytes`

I had it like that but previous reviewers complained about the name. I made it longer to make sure that it is as clear as possible what this value is about. IMHO, one of the reasons why this code was hard to figure out why it was broken was because the names where not precise enough to explain what was stored in the variables.

Let me try to go the other way and completely remove the "unsampled" name. And then you can take a look and see if you really hate it and if you do I'll take a stab at finding some shorter names that still are descriptive for the casual reader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095012687

From stefank at openjdk.org  Mon May 19 08:28:45 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 08:28:45 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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

 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - Tweak names
 - Fix sample threshold setup
 - Apply suggestions from code review
   
   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
 - Re-enable tests after merge
 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/a318053e..dd6d8b4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=02-03

  Stats: 28120 lines in 704 files changed: 10509 ins; 13536 del; 4075 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

PR: https://git.openjdk.org/jdk/pull/25114

From sspitsyn at openjdk.org  Mon May 19 09:28:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:28:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
 <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>
Message-ID: <WTc3Tc0NS0u0maMaB1DwU398fs_3rt0lYHxn_SJw3bM=.fd13c38f-878d-4670-9513-de8433d222d2@github.com>

On Mon, 19 May 2025 07:22:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.hpp line 92:
>> 
>>> 90:   }
>>> 91: 
>>> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {
>> 
>> Nit: I wonder if we can make names shorter with replacing:
>>   `bytes_since_last_sample` => `unsampled_bytes`
>
> I had it like that but previous reviewers complained about the name. I made it longer to make sure that it is as clear as possible what this value is about. IMHO, one of the reasons why this code was hard to figure out why it was broken was because the names where not precise enough to explain what was stored in the variables.
> 
> Let me try to go the other way and completely remove the "unsampled" name. And then you can take a look and see if you really hate it and if you do I'll take a stab at finding some shorter names that still are descriptive for the casual reader.

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095271858

From sspitsyn at openjdk.org  Mon May 19 09:36:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:36:52 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
Message-ID: <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>

On Fri, 16 May 2025 18:41:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.hpp line 89:
> 
>> 87: 
>> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
>> 89:     pick_next_sample();
> 
> The old identifier is used: _bytes_until_sample.

This comment still need a fix as this name was removed by this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095287505

From sspitsyn at openjdk.org  Mon May 19 09:43:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:43:56 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
Message-ID: <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>

On Mon, 19 May 2025 08:28:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - Tweak names
>  - Fix sample threshold setup
>  - Apply suggestions from code review
>    
>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>  - Re-enable tests after merge
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Stefan, thank you for the update. The whole fix looks good in general. I like the refactoring.
One comment still need an update though as it has a removed/renamed field name.

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

PR Comment: https://git.openjdk.org/jdk/pull/25114#issuecomment-2890353605

From jsjolen at openjdk.org  Mon May 19 10:08:04 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 19 May 2025 10:08:04 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
Message-ID: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>

Hi,

 The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:

```c++
struct BSMAE {
  u2 bootstrap_method_index;
  u2 argument_count;
  u2 arguments[argument_count];
}


We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 

Please consider!

Testing: Currently GHA, running tier1-tier3

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

Commit messages:
 - Introduce BSMAttributeEntry

Changes: https://git.openjdk.org/jdk/pull/25298/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357220
  Stats: 102 lines in 7 files changed: 33 ins; 35 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/25298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25298/head:pull/25298

PR: https://git.openjdk.org/jdk/pull/25298

From gli at openjdk.org  Mon May 19 11:08:56 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 19 May 2025 11:08:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
Message-ID: <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>

On Mon, 19 May 2025 06:04:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I don't think throwing OOM, from gc's perspective, is an "error".

Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2095458632

From gli at openjdk.org  Mon May 19 11:08:59 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 19 May 2025 11:08:59 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]
In-Reply-To: <H2qJqlfNPnNvzAHU4zNiXLe52fhQeYEvjuArrRmZTBY=.6e9501bd-e617-4322-8f9e-02453ec9b7eb@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
 <Iqn9aLoZslR6GspSVdG2t-w4GDStBKIkXSLmtlRw6k0=.77363a98-248f-4229-a3e2-c15c2ac59ad1@github.com>
 <H2qJqlfNPnNvzAHU4zNiXLe52fhQeYEvjuArrRmZTBY=.6e9501bd-e617-4322-8f9e-02453ec9b7eb@github.com>
Message-ID: <v1AQGlTvq4O8hySEOQg1Jj1g49gvY7YHC07bqdRNv10=.5951aeb6-9570-481d-9d5a-e69f788f582d@github.com>

On Mon, 19 May 2025 05:20:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 232:
>> 
>>> 230:     // Major times are too long, so we want less promotion.
>>> 231:     incr_tenuring_threshold = true;
>>> 232:   }
>> 
>> You keep the condition `minor_cost > major_cost * _threshold_tolerance_percent` of the previous code. But it will be strange when we only read the new code (in the future). What about removing the condition `minor_cost > major_cost * _threshold_tolerance_percent` and moving the comment `we prefer young-gc over full-gc` to another place?
>
> I keep it this way because I find the structure to be more symmetric, but I don't have a strong opinion on this. If you prefer, I can remove the empty if-branch. (The resulting asm should be identical.)

I prefer removing it; waiting for opinions by other reviewers.

>> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 254:
>> 
>>> 252:     // survived is an underestimate
>>> 253:     _survived_bytes.add(survived + promoted);
>>> 254:   }
>> 
>> The parameter `is_survivor_overflow` seems unnecessary. When `is_survivor_overflow` is `false`, the `promoted` is `0`. What about using `_survived_bytes.add(survived + promoted)` only and removing parameter `is_survivor_overflow` (and the related conditional code).
>
>> When is_survivor_overflow is false, the promoted is 0
> 
> That's not true; objs that live long enough will be promoted as well, even when the survivor-space has plenty of free-space.

Ohh, you are right, I forgot it at that time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2095457633
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2095457808

From gli at openjdk.org  Mon May 19 11:09:00 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 19 May 2025 11:09:00 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
Message-ID: <0l1GXiRVXTfUaPsDPyirWY0RnyyjxO95GfqnED2O1nw=.6f9d7504-3708-48f0-9e28-689772339276@github.com>

On Mon, 19 May 2025 05:49:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> If all live-objs don't fit in old-gen, leftovers will be kept in its own space.

Thanks for clarifying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2095458158

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/dd6d8b4d..ea0c8c7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/25114

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
 <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>
Message-ID: <Re1dZUeCELI5_A3XuixwKKcH5jWY8XdXtRX3XNQGMqg=.94cb1e92-9192-4204-8aa9-d16f562d0912@github.com>

On Mon, 19 May 2025 07:11:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.cpp line 399:
>> 
>>> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
>>> 398:   size_t interval = static_cast<size_t>(result);
>>> 399:   _sample_threshold = interval;
>> 
>> Nit: The line 399 is not needed as the value is reset at 400.
>
> Nice catch. This is debugging code from the early stage of this patch. It set up a consistent state to make it easier to get consistent data from the test runs. This also means that we need to respin our testing to make sure that the randomization doesn't trigger anything that we didn't catch with the fixed _sample_threshold.

The unit tests still pass after the fix for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095512240

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
 <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>
Message-ID: <sCmXP1F3e_qhqkjo5PQxCZzGE07sVywGk2k5Tt102m0=.1d529f55-1ccb-4fb8-bed7-1bdb9a013bdf@github.com>

On Mon, 19 May 2025 09:34:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.hpp line 89:
>> 
>>> 87: 
>>> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
>>> 89:     pick_next_sample();
>> 
>> The old identifier is used: _bytes_until_sample.
>
> The comment at line 89 still need a tweak as the name `_bytes_until_sample` is being removed by this fix.

Thanks! I've now updated the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095510797

From stefank at openjdk.org  Mon May 19 11:44:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:44:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
 <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>
Message-ID: <WFWQzi3h5hVwBL6fkBqg6AxlC9ICtXfsfPwj7VIF5qg=.7c963345-0324-4881-ab2f-c7535ae99683@github.com>

On Mon, 19 May 2025 09:40:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>>  - Tweak names
>>  - Fix sample threshold setup
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>>  - Re-enable tests after merge
>>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations
>
> Stefan, thank you for the update. The whole fix looks good in general. I like the refactoring.
> One comment still need an update though as it has a removed/renamed field name.

Thanks, @sspitsyn! I think I've addressed all your comments now except making the names shorter. I hope that's OK and if we really want to shorten then, I don't mind doing it in a follow-up RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/25114#issuecomment-2890697415

From duke at openjdk.org  Mon May 19 12:06:58 2025
From: duke at openjdk.org (NeatGuyCoding)
Date: Mon, 19 May 2025 12:06:58 GMT
Subject: RFR: 8356177: Regression after JDK-8352180 [v2]
In-Reply-To: <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
References: <o4-2SIzWEhCqDhXLYRvF1ajPi3RsfX7O8u5iAgXNFmE=.931d8d5b-3880-4425-a72e-40d9c783288a@github.com>
 <RW9wj9miw-F71EaXZ4Nn3EvhMjmQ9oGNXjVzUSqX1B4=.583e0ddc-555f-450f-b022-b5ce5312be30@github.com>
Message-ID: <oOaQNXrEfv-clUpr3p1SyYjoXnk5lfrnfooVMxjVWto=.8c473a70-935f-4549-8c61-1dede78b1ce5@github.com>

On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

@NeatGuyCoding

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

PR Comment: https://git.openjdk.org/jdk/pull/25219#issuecomment-2890761017

From jbechberger at openjdk.org  Mon May 19 13:12:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 19 May 2025 13:12:39 GMT
Subject: RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental)
Message-ID: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>

This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).

Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
- ... different heap sizes
- ... different GCs
- ... different samplers (the standard JFR and the new CPU Time Sampler and both)
- ... different JFR recording durations
- ... different chunk-sizes

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

Depends on: https://git.openjdk.org/jdk/pull/24296

Commit messages:
 - Remove unused WhiteBox method
 - Read _active_signal_handlers atomically
 - Check whether raw_thread is not null and is JavaThread is signal handler
 - Tiny fixes
 - Fix uninitialized variable
 - Reduce diff
 - Refactor
 - Reduce diff
 - Reduce diff
 - Tiny fixes
 - ... and 11 more: https://git.openjdk.org/jdk/compare/71c284ae...d180ce01

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337789
  Stats: 2335 lines in 46 files changed: 2184 ins; 130 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 19 14:25:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 19 May 2025 14:25:33 GMT
Subject: RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental) [v2]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <pBte2AJ20VWRwcADAuM4s-Z8bFII64LmItF37JVejzs=.b4cf740a-ffbf-499b-a10a-996a074ade39@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Remove unused WhiteBox method
 - Read _active_signal_handlers atomically
 - Check whether raw_thread is not null and is JavaThread is signal handler
 - Tiny fixes
 - Fix uninitialized variable
 - Reduce diff
 - Refactor
 - Reduce diff
 - Reduce diff
 - Tiny fixes
 - ... and 11 more: https://git.openjdk.org/jdk/compare/46566a9b...24216fe8

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=01
  Stats: 2335 lines in 46 files changed: 2184 ins; 130 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From sspitsyn at openjdk.org  Mon May 19 14:52:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 14:52:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
Message-ID: <8cfhMuruRD9FElCefMcCv672JxoDoCKFPkfKfylmZy4=.ae2a6901-275a-4405-a9a4-9597e1c7d168@github.com>

On Mon, 19 May 2025 11:40:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Looks good. Thank you for the update!
I'm okay with current naming. Consistency is more important than shortness.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2851051486

From jbechberger at openjdk.org  Mon May 19 17:06:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 19 May 2025 17:06:09 GMT
Subject: RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental) [v3]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <vi1b4ZQMnv0D_EY87SHq8QLMXkjAgrGPuuKpELiZGms=.b862565e-7a27-47f1-8dde-9b2435332753@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/24216fe8..61a3ee2d

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

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From cjplummer at openjdk.org  Mon May 19 17:52:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 19 May 2025 17:52:53 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <XsSMHjFwdUj4jxXcuEFj1ryPAe3H7vZWn-dUIX9b9s4=.9b1ea875-491e-42bf-97f3-e99773b1c0f1@github.com>

On Mon, 19 May 2025 07:35:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 126:

> 124:   private static int INDY_BSM_OFFSET = 0;
> 125:   private static int INDY_ARGC_OFFSET = 1;
> 126:   private static int INDY_ARGV_OFFSET = 2;

Is the SA code that references these fields still correct? It seems the references are from the ClassWriter, which we don't have very good test coverage for. Probably this is a bug that is not being detected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2096231130

From sspitsyn at openjdk.org  Mon May 19 17:56:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 17:56:52 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <U1kvIztuzqBy37VwHjY6mEhlZkmd9h613jbg-t2thNw=.e94d457f-ae13-47f7-976d-2c43c3ecd79d@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
 <U1kvIztuzqBy37VwHjY6mEhlZkmd9h613jbg-t2thNw=.e94d457f-ae13-47f7-976d-2c43c3ecd79d@github.com>
Message-ID: <ErBKTzoF-sHTkEoG1Af0uQZIsNpQdTLJtBZ_Da6fulY=.33c1e316-bcf2-48ab-8728-e05e133c800d@github.com>

On Mon, 19 May 2025 05:26:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I can suppress it by extracting JVMTI_VERSION into local variable similar to how other code looks like:
>
>    jint version = JVMTI_VERSION;
>    jvmtiCompileTimeMajorVersion  = ( version & JVMTI_VERSION_MASK_MAJOR )
>                                        >> JVMTI_VERSION_SHIFT_MAJOR;
>    jvmtiCompileTimeMinorVersion  = ( version & JVMTI_VERSION_MASK_MINOR )
>                                        >> JVMTI_VERSION_SHIFT_MINOR;
>    jvmtiCompileTimeMicroVersion  = ( version & JVMTI_VERSION_MASK_MICRO )
>                                        >> JVMTI_VERSION_SHIFT_MICRO;
>
> but it might be better just suppress it in the make file?

I like the suggestion to extract JVMTI_VERSION into a local variable. Fixing it in the make file is fine too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2891829112

From iklam at openjdk.org  Mon May 19 21:42:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 19 May 2025 21:42:11 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v10]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <QphyWVNxJwa5w5He9DF8ocx_5ZRa3YzL5C2t-fvZH7U=.a4108e28-43f0-463b-8a5b-12ad9ed4dd6f@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'master' into 8356595-convert-cds-log-to-aot-log
 - @jdksjolen review comments
 - Merge master
 - Fixed makefile; Fixed copyright
 - Merge branch 'master' into 8356595-convert-cds-log-to-aot-log
 - Improved comments: [cds] logs will be printed if no -XX:AOTxxx flags are used
 - @dholmes-ora review - fixed typos
 - Removed PrintAOTLogsAsCDSLogs and improved comments
 - More conversion; clean up; bug fixes
 - Fixed macos build
 - ... and 20 more: https://git.openjdk.org/jdk/compare/fbeea1da...8ce133da

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

Changes: https://git.openjdk.org/jdk/pull/25136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=09
  Stats: 717 lines in 48 files changed: 315 ins; 9 del; 393 mod
  Patch: https://git.openjdk.org/jdk/pull/25136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25136/head:pull/25136

PR: https://git.openjdk.org/jdk/pull/25136

From iklam at openjdk.org  Mon May 19 22:49:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 19 May 2025 22:49:10 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v11]
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <TItCdq8UMPN93n-rGjWVqNCuQ4aENZ8k7b8eAQ83MwU=.54d48018-9c0e-4655-9dfe-5d2299b2ce0f@github.com>

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25136/files
  - new: https://git.openjdk.org/jdk/pull/25136/files/8ce133da..4a2aa74a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25136&range=09-10

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

PR: https://git.openjdk.org/jdk/pull/25136

From serb at openjdk.org  Mon May 19 23:03:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 23:03:53 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <u7PKX4rxqYrjsNOUA7TSpIIMmZZl3sbvlRBiZ8N2qgs=.27b4da1c-d199-4e24-8680-35c10d921630@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

I guess everyone agreed to disable the warning in the makefile

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

PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2892470978

From iveresov at openjdk.org  Tue May 20 00:37:14 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 20 May 2025 00:37:14 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v22]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <_HjblHzZnDzpYl3gZrcQL7FWeqJ_7jxEY_LwHQV6AiU=.ad599c04-7bd1-48db-9485-dd0dab940930@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 87 commits:

 - Merge branch 'master' into pp2
 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform
 - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
   
   Reviewed-by: vlivanov, kvn
 - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
   
   Reviewed-by: naoto
 - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()
   
   Reviewed-by: wkemper
 - ... and 77 more: https://git.openjdk.org/jdk/compare/890456f0...2740c2f2

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=21
  Stats: 3325 lines in 59 files changed: 3111 ins; 100 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From ccheung at openjdk.org  Tue May 20 01:11:54 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 20 May 2025 01:11:54 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v11]
In-Reply-To: <TItCdq8UMPN93n-rGjWVqNCuQ4aENZ8k7b8eAQ83MwU=.54d48018-9c0e-4655-9dfe-5d2299b2ce0f@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <TItCdq8UMPN93n-rGjWVqNCuQ4aENZ8k7b8eAQ83MwU=.54d48018-9c0e-4655-9dfe-5d2299b2ce0f@github.com>
Message-ID: <rBJSGlLWFhiBi-L-C4R4PL5Fhi8aUv_zvzL84RCOge8=.ed4bbeb0-1764-47ba-9db6-a09c20eec3a4@github.com>

On Mon, 19 May 2025 22:49:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
>> 
>> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
>> 
>> Please see **aotLogging.hpp** for how the macros work.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed merge

Marked as reviewed by ccheung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25136#pullrequestreview-2852271858

From iklam at openjdk.org  Tue May 20 03:47:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 May 2025 03:47:00 GMT
Subject: RFR: 8356595: Convert -Xlog:cds to -Xlog:aot (step1) [v4]
In-Reply-To: <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
 <xWjDz3heE7nYOMWNyo0Fcv4oNAEfZKekugpyaadRloo=.93177951-6bbc-47ec-a8e9-6b56e512dde8@github.com>
 <RGemnS_jI2nsceayzxkeotJEwKwfpv2C0Ov1n6X1iBM=.d10d494c-9b0b-41f0-b8e8-ea48bce3f212@github.com>
Message-ID: <_5f2Eg9-l35N9EiY-u-THofrkIPSshWR72CuZcqJ5R4=.3b7b4b64-26fc-4f41-a64d-274cd6bcb252@github.com>

On Wed, 14 May 2025 06:35:12 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed PrintAOTLogsAsCDSLogs and improved comments
>
> Hi,
> 
> Just one comment. I'm approving, the UL code looks good to me.

Thanks @jdksjolen @dholmes-ora @matias9927 @calvinccheung for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25136#issuecomment-2892816466

From iklam at openjdk.org  Tue May 20 03:47:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 May 2025 03:47:01 GMT
Subject: Integrated: 8356595: Convert -Xlog:cds to -Xlog:aot (step1)
In-Reply-To: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
References: <yf8je0NfvEQYpnLKb-tgBFuWRSyKyVqqv9Eu_K64kAc=.487a5bf2-2830-4e54-af61-eb621add102d@github.com>
Message-ID: <GgU1FS4eNg6R-Tj8Ppl9ukCD88H6OPXwakl992WR-6Y=.34d17448-af77-4f6d-8d35-8adbd8cc1fe0@github.com>

On Fri, 9 May 2025 03:53:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative (and opposite) approach to https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]` logs to `[aot]` logs. However, for the few logs that might be needed by existing user scripts, we use macros like `aot_log_info`, `aot_log_debug` so that they can be selected/printed using the `[cds]` tag. 
> 
> We have a few hundred logs that start with `[cds]`. To aid reviewing, this PR will convert only part of them. The rest of the logs are converted in https://github.com/openjdk/jdk/pull/25238. Both PRs will be integrated at the same time after review.
> 
> Please see **aotLogging.hpp** for how the macros work.

This pull request has now been integrated.

Changeset: 7077535c
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3
Stats:     719 lines in 49 files changed: 315 ins; 9 del; 395 mod

8356595: Convert -Xlog:cds to -Xlog:aot (step1)

Reviewed-by: ccheung, dholmes, jsjolen, matsaave

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

PR: https://git.openjdk.org/jdk/pull/25136

From sjohanss at openjdk.org  Tue May 20 06:27:53 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 20 May 2025 06:27:53 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
Message-ID: <HA4_0k1Pnjx81E9mBkXbS6SjBRSsS6ap_C8kJeDHOOA=.00647189-6a9f-466d-9b0c-7f9ffb0941e8@github.com>

On Mon, 19 May 2025 11:40:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

src/hotspot/share/runtime/threadHeapSampler.cpp line 423:

> 421:   if (log.is_enabled()) {
> 422:     const bool should_sample = bytes_since_last_sample(tlab_top) >= _sample_threshold;
> 423:     log_debug(gc, tlab)("Should sample: %s _sample_threshold: %zu total: %zu tlab: %zu current tlab: %zu outside_tlab: %zu",

Suggestion:

    log_debug(gc, tlab)("Should sample: %s _sample_threshold: %zu total: %zu tlab: %zu current tlab: %zu outside tlab: %zu",

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2097025408

From jsjolen at openjdk.org  Tue May 20 06:36:54 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 20 May 2025 06:36:54 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <_Q_te2sCDXdotlpdBM1abTLipHBNnqXLKPbcJdbQGlw=.abb4e764-a26e-4e7c-a3da-6a490aa2e676@github.com>

On Mon, 19 May 2025 07:35:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

src/hotspot/share/oops/constantPool.hpp line 578:

> 576:          _indy_argv_offset = 2   // u2 argv[argc]
> 577:   };
> 578: 

@plummercj , this is where the enum constants come from.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2097063232

From jsjolen at openjdk.org  Tue May 20 06:36:55 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 20 May 2025 06:36:55 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <XsSMHjFwdUj4jxXcuEFj1ryPAe3H7vZWn-dUIX9b9s4=.9b1ea875-491e-42bf-97f3-e99773b1c0f1@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <XsSMHjFwdUj4jxXcuEFj1ryPAe3H7vZWn-dUIX9b9s4=.9b1ea875-491e-42bf-97f3-e99773b1c0f1@github.com>
Message-ID: <dxRhh7QO7C9VHnpd9mU0YRUnDgT80BrSIxLiJYDBIIE=.98bd093b-de12-4438-bb73-579dfcd02745@github.com>

On Mon, 19 May 2025 17:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 126:
> 
>> 124:   private static int INDY_BSM_OFFSET = 0;
>> 125:   private static int INDY_ARGC_OFFSET = 1;
>> 126:   private static int INDY_ARGV_OFFSET = 2;
> 
> Is the SA code that references these fields still correct? It seems the references are from the ClassWriter, which we don't have very good test coverage for. Probably this is a bug that is not being detected.

The references are still correct, as we haven't changed the struct layout. We're also not planning on doing so. I don't think that there is a bug here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2097067592

From stefank at openjdk.org  Tue May 20 07:14:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 May 2025 07:14:39 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/threadHeapSampler.cpp
  
  Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/ea0c8c7c..aa006f98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/25114

From sjohanss at openjdk.org  Tue May 20 07:14:39 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 20 May 2025 07:14:39 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <3vaduHUfzw_A9KmpHmEIJ0Eqow6G_g6goUIhJZVX5Fc=.ee325778-f05e-4a84-8543-138522a242de@github.com>

On Tue, 20 May 2025 07:10:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2852945669

From sspitsyn at openjdk.org  Tue May 20 10:58:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 May 2025 10:58:00 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <UGatIBNvFwqKXwVXv0dXK8ZRdkSZCQGjhK0_ZqTqkTc=.2d6bac35-29c5-4d76-a991-ae757df14f8b@github.com>

On Tue, 20 May 2025 07:14:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2853704891

From sspitsyn at openjdk.org  Tue May 20 10:58:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 May 2025 10:58:53 GMT
Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum
 type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <F060NDtIVkXn3B6pCq7xxXTRcGDnVvHlgak47GMZl3A=.a705157b-2661-4e2b-a51d-e7145f455568@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25293#pullrequestreview-2853707197

From stefank at openjdk.org  Tue May 20 13:49:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 May 2025 13:49:02 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <-8tAtM1OKthqHMXlA7TgOsh6RCz5dGvSHgpscyhhCpo=.25653274-38ff-4517-ba7a-eac23d801a85@github.com>

On Tue, 20 May 2025 07:14:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Thanks for the reviews! If final testing passes I plan to integrate tomorrow (unless new reviewers show up).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2854266934

From mbaesken at openjdk.org  Tue May 20 14:31:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 May 2025 14:31:56 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <abCkeuV_7MvS3ujbXMTmSDo9Wg0mA64breaErU1hwpI=.a6ca0c0e-400b-40ba-9cb7-79342e2920c2@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

>> I think you proposed something like this ?
> I think so.

Do you plan to propose such a PR ?
But without benchmarks for the JDK native libs some people might have concerns .

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2894644441

From sspitsyn at openjdk.org  Tue May 20 18:16:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 May 2025 18:16:57 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v9]
In-Reply-To: <VCwfxQQmdmNx56-n-LtSPnTsj95gjz-B5HmsecOnGwQ=.e84e134a-d1e0-40bd-ba06-2b40d78ec8e7@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <VCwfxQQmdmNx56-n-LtSPnTsj95gjz-B5HmsecOnGwQ=.e84e134a-d1e0-40bd-ba06-2b40d78ec8e7@github.com>
Message-ID: <tlGpuwZuL2pBncnd-CaeiJYw_GiXFirZiaDpUP7aIes=.f0b7c9d3-bdb8-40dc-b06b-a7c7fa7670ef@github.com>

On Sat, 17 May 2025 05:04:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2855165262

From amenkov at openjdk.org  Tue May 20 18:50:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 20 May 2025 18:50:58 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v9]
In-Reply-To: <VCwfxQQmdmNx56-n-LtSPnTsj95gjz-B5HmsecOnGwQ=.e84e134a-d1e0-40bd-ba06-2b40d78ec8e7@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <VCwfxQQmdmNx56-n-LtSPnTsj95gjz-B5HmsecOnGwQ=.e84e134a-d1e0-40bd-ba06-2b40d78ec8e7@github.com>
Message-ID: <rxw4b0QwKppcQKcZO0aOmF8H_uL3-2Jf06f4mqSiO68=.b1889ec6-94e1-4b26-b3f8-bee38f27580a@github.com>

On Sat, 17 May 2025 05:04:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspend/suspend001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

The only change in the file is copyright update

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

one more

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

one more

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001/TestDescription.java line 1:

> 1: /*

one more

test/hotspot/jtreg/vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn001/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

one more

test/hotspot/jtreg/vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn002/TestDescription.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

one more

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType2.java line 2:

> 1: /*
> 2:  * Copyright (c) 2006, 2025, Oracle and/or its affiliates. All rights reserved.

one more

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098647362
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098648012
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098648378
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098648645
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098649765
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098649896
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650025
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650158
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650307
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650514
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650799
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098650969
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098651449
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098651599
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098651728
PR Review Comment: https://git.openjdk.org/jdk/pull/24606#discussion_r2098651980

From cjplummer at openjdk.org  Tue May 20 19:33:34 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 May 2025 19:33:34 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - undo errant copyright updates
 - undo errant copyright updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24606/files
  - new: https://git.openjdk.org/jdk/pull/24606/files/b5e25f01..ee15c9e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=08-09

  Stats: 16 lines in 16 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606

PR: https://git.openjdk.org/jdk/pull/24606

From amenkov at openjdk.org  Tue May 20 19:33:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 20 May 2025 19:33:34 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <-G2jN-cX3xAtTIrh0vSpqTZRaQDzWiuL5K46N_2LGGs=.e0fdb3e3-e5b8-4c2b-b2d6-78fe93553aeb@github.com>

On Tue, 20 May 2025 19:29:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2855355758

From sspitsyn at openjdk.org  Tue May 20 20:18:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 May 2025 20:18:55 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <l67ShxJjC8KAG-BC5RCDVG1ew-BFudavVg2-ZctLvtM=.a6cdeec3-4e77-4e6a-9da6-2a189178e94e@github.com>

On Tue, 20 May 2025 19:33:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2855461678

From cjplummer at openjdk.org  Tue May 20 20:22:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 May 2025 20:22:36 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture exceptions
 thrown by Debuggee.classByName()
Message-ID: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>

Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.

There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.

Tested nsk/jdi test locally. Will do more thorough ci testing.

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

Commit messages:
 - Extend try block to cover debuggee.classByname() call

Changes: https://git.openjdk.org/jdk/pull/25337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357172
  Stats: 514 lines in 22 files changed: 145 ins; 199 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/25337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25337/head:pull/25337

PR: https://git.openjdk.org/jdk/pull/25337

From cjplummer at openjdk.org  Tue May 20 20:26:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 May 2025 20:26:54 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <dxRhh7QO7C9VHnpd9mU0YRUnDgT80BrSIxLiJYDBIIE=.98bd093b-de12-4438-bb73-579dfcd02745@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <XsSMHjFwdUj4jxXcuEFj1ryPAe3H7vZWn-dUIX9b9s4=.9b1ea875-491e-42bf-97f3-e99773b1c0f1@github.com>
 <dxRhh7QO7C9VHnpd9mU0YRUnDgT80BrSIxLiJYDBIIE=.98bd093b-de12-4438-bb73-579dfcd02745@github.com>
Message-ID: <YwRARMZsI1v1_pp-fiPhXQcCMGoCYckkPBnjCcPrRuE=.0033d123-0533-41d2-b02f-f108bd22bdb3@github.com>

On Tue, 20 May 2025 06:34:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 126:
>> 
>>> 124:   private static int INDY_BSM_OFFSET = 0;
>>> 125:   private static int INDY_ARGC_OFFSET = 1;
>>> 126:   private static int INDY_ARGV_OFFSET = 2;
>> 
>> Is the SA code that references these fields still correct? It seems the references are from the ClassWriter, which we don't have very good test coverage for. Probably this is a bug that is not being detected.
>
> The references are still correct, as we haven't changed the struct layout. We're also not planning on doing so. I don't think that there is a bug here.

Ok. It's just unusual to see constants like these that are needed by SA but serve no purpose in hotspot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2098809598

From lmesnik at openjdk.org  Tue May 20 21:14:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 20 May 2025 21:14:02 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <B6SvpCIqp2ZguL_j6fjabZSFSjtcQVNrr8v8KLSP96g=.b020be6d-1981-4a0c-ac94-2aa37d4ee61a@github.com>

On Tue, 20 May 2025 19:33:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

It is unclear to me if 
-includevirtualthreads requires to pass test in default mode or with virtual thread test factory?

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2855603544

From jrose at openjdk.org  Tue May 20 21:44:54 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 20 May 2025 21:44:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
Message-ID: <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>

On Mon, 5 May 2025 06:35:39 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.cpp line 52:
>> 
>>> 50: 
>>> 51: int FieldInfoStream::compare_symbols(const Symbol *s1, const Symbol *s2) {
>>> 52:   // not lexicographical sort, since we need only total ordering
>> 
>> If only a total ordering is required, why defining a new method instead of reusing Symbol::fast_compare() ?
>
> The problem is CDS; I have really started with `fast_compare()`, but after dehydration the pointers changed and the comparison did not work anymore. This is also a reason why I could not use the hashcode for the ordering.
> If you'd prefer lexicographical sort (just a few extra lines) I could use that one...

It's not good to introduce a new symbol comparator in a random place.  Symbol comparators should be defined and maintained centrally, in symbol.[ch]pp.

If there's a bug with fast_compare, I want us to fix it eventually.  So for now, define a companion function in symbol.hpp called fast_compare_cds_safe.  We can work with it from there.  You can use your proposed logic but we will probably want to fiddle with it, and probably merge it with fast_compare (per se) if CDS can be adjusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2098921193

From cjplummer at openjdk.org  Tue May 20 21:54:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 May 2025 21:54:54 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <B6SvpCIqp2ZguL_j6fjabZSFSjtcQVNrr8v8KLSP96g=.b020be6d-1981-4a0c-ac94-2aa37d4ee61a@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
 <B6SvpCIqp2ZguL_j6fjabZSFSjtcQVNrr8v8KLSP96g=.b020be6d-1981-4a0c-ac94-2aa37d4ee61a@github.com>
Message-ID: <jFygl6-ghsRxsSDXx2QZ9grnzOtgzv2MUFvXLxSN5OM=.9d7f25c2-0a17-4abc-9356-5a69e64f3daf@github.com>

On Tue, 20 May 2025 21:10:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> It is unclear to me if
> -includevirtualthreads requires to pass test in default mode or with virtual thread test factory?

It means launch the debug agent with includevirtualthreads=y. It does the same regardless of the test factory type. Probably the logic that actually passes the argument (see the change in Binder.java) could be modified to only do so when using the virtual thread factory, but it is harmless to add it when running only with platform threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2895916024

From lmesnik at openjdk.org  Tue May 20 22:07:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 20 May 2025 22:07:53 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <9EPZh3ojuj0Zm2C4ls4NLwcgwb1VCeIU1VtwHpd1Wlc=.5e2b94ba-4b16-4eec-812a-5e4287fd7444@github.com>

On Tue, 20 May 2025 19:33:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24606#pullrequestreview-2855699783

From lmesnik at openjdk.org  Tue May 20 22:07:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 20 May 2025 22:07:54 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <jFygl6-ghsRxsSDXx2QZ9grnzOtgzv2MUFvXLxSN5OM=.9d7f25c2-0a17-4abc-9356-5a69e64f3daf@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
 <B6SvpCIqp2ZguL_j6fjabZSFSjtcQVNrr8v8KLSP96g=.b020be6d-1981-4a0c-ac94-2aa37d4ee61a@github.com>
 <jFygl6-ghsRxsSDXx2QZ9grnzOtgzv2MUFvXLxSN5OM=.9d7f25c2-0a17-4abc-9356-5a69e64f3daf@github.com>
Message-ID: <-I_HVPmQv01hhzEZWGZz8z7d9cMwlBLidjYapRXSu0E=.4698208e-baff-4f76-8cf6-7c43f70f7348@github.com>

On Tue, 20 May 2025 21:52:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It means launch the debug agent with includevirtualthreads=y. It does the same regardless of the test factory type. Probably the logic that actually passes the argument (see the change in Binder.java) could be modified to only do so when using the virtual thread factory, but it is harmless to add it when running only with platform threads.

Thanks for explanation. The fix looks good. The only one question - if it does make sense to run test suite in 2 modes: with and without -includevirtualthreads or force -includevirtualthreads when virtual threads are enabled? Does it provide any additional coverage or only spending efforts.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2895937748

From jrose at openjdk.org  Tue May 20 22:41:55 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 20 May 2025 22:41:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
Message-ID: <tJphdpLT6x1PEWUE6K7kDPKFmis2Kq1Ndy-nfu6w32s=.8e4d70e4-01d6-4746-aa25-a3fe60eaf6bd@github.com>

On Wed, 14 May 2025 12:46:41 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Revert change in array.hpp
>  - Revert changes in VerifyRawIndexesTest
>  - Improve FieldInfo::print
>  - Load constant for SORTED_FIELD_TABLE_THRESHOLD
>  - Replace JumpTable with SortedFieldTable

Please move comparison logic to `Symbol::fast_compare_cds_safe`, where it will be more maintainable.

Please do not store ad hoc non-compressed data in a CompressedStream.  Compressed streams used to have such junk in them, and we worked hard to clean them up.  Compression is easier to maintain and enhance when it is consistently used.  That would also have been my objection to the control bytes in PR 24713.

I confirm that the main field-info stream should *not* be reordered.  That is likely to harm users which are sensitive to encounter order.

Instead, a side array should binary-searched.

Please use a separate Array<u1> to store the side array.

(More comments on the format of that side array are likely, but it makes sense to have each entry consist of a secondary key .)

This design will be more refactorable, for when we need the same thing for PC range and/or reloc info and/or other streamy data that may need indexing.

One thing that is hard to live with (maintain, enhance) is a single array that contains two or more sub-segments.  It is that way with the bootstrap method indices in the constant pool, but the ownership costs are high, and we are working to get free of that sort of local optimization.  This is why I am confident of asking for a second array, rather than clever repacking of the first array.

If the 8 bytes of the second array really are important (they are not, presently), we can make that (and/or other) pointers in InstanceKlass be optional, as some fields in Method are optional today.

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

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2855741807

From cjplummer at openjdk.org  Tue May 20 22:58:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 May 2025 22:58:52 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <-I_HVPmQv01hhzEZWGZz8z7d9cMwlBLidjYapRXSu0E=.4698208e-baff-4f76-8cf6-7c43f70f7348@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
 <B6SvpCIqp2ZguL_j6fjabZSFSjtcQVNrr8v8KLSP96g=.b020be6d-1981-4a0c-ac94-2aa37d4ee61a@github.com>
 <jFygl6-ghsRxsSDXx2QZ9grnzOtgzv2MUFvXLxSN5OM=.9d7f25c2-0a17-4abc-9356-5a69e64f3daf@github.com>
 <-I_HVPmQv01hhzEZWGZz8z7d9cMwlBLidjYapRXSu0E=.4698208e-baff-4f76-8cf6-7c43f70f7348@github.com>
Message-ID: <2YAVO8LRzePwmGjWeXs4iyKLaSJE2twDWydEuXOdcP0=.b5942b1b-f6b3-4c85-b695-703c6b9acb8b@github.com>

On Tue, 20 May 2025 22:04:54 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Thanks for explanation. The fix looks good. The only one question - if it does make sense to run test suite in 2 modes: with and without -includevirtualthreads or force -includevirtualthreads when virtual threads are enabled? Does it provide any additional coverage or only spending efforts.

We could run with all tests using includevirtualthreads=y, which is basically what we have been doing. I don't think that testing is very useful. Debuggers in general aren't using (and shouldn't be using) includevirtualthreads=y. The main reason it was added was so we could run our test suites because so many tests relied on vm.allThreads() returning the debuggee virtual threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2896009954

From jrose at openjdk.org  Tue May 20 23:03:55 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 20 May 2025 23:03:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
 <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
Message-ID: <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>

On Fri, 16 May 2025 23:51:39 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Revert change in array.hpp
>>  - Revert changes in VerifyRawIndexesTest
>>  - Improve FieldInfo::print
>>  - Load constant for SORTED_FIELD_TABLE_THRESHOLD
>>  - Replace JumpTable with SortedFieldTable
>
> This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.
> 
> I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.
> 
> It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.
> 
> It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.
> 
> BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.
> 
> The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.
> 
> One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.
> 
> I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.

> @rose00 While refactoring might be useful, this PR is trying to address a performance regression (in fact by improving the scenario significantly), and I'd prefer that to land in 25

It will land when it's ready.  It's not quite ready yet.  I'm not asking for reusability, but I am saying that doing a one-off index hack here is exchanging one kind of technical debt (maintenance complexity) for another (performance pothole).  If we hustle to make 25, we need a plan to fix it after 25.

> rather than to delay just for the sake of better 'reusability'.

Yes, 'reusability'.  That's how big systems are maintained.

> And TBH I don't consider binary search algorithm too difficult to validate.

TBH I do.  I've seen enough OBOEs for one lifetime.  I don't consider even that simple an algorithm to be fully tested unless it is either unit tested (gtest) or stress tested (threshold set small), and preferably both.  Testing it for just a few classes that have many fields is not full coverage.  (Normally for this kind of thing, your hard-coded constant 16 would be made a debug-only globals, and we'd stress-test with it set to 1 or 2.)   Writing a unit test requires enough factorization to write the unit test.  Which also tends towards virtuous reusability.

> While a simple cache might be useful, I don't have a good example to validate its usefulness. And turning a read-only scenario into mutating scenario can turn out badly for multithreaded code, as in https://bugs.openjdk.org/browse/JDK-8180450 .

No worries about this one; I'm not asking for such a thing, just noting in passing that it sometimes helps.  Probably not in this case, since you didn't resort the original array, and the usual sequential encounter order is direct, not requiring a cache.  If we were re-engineering PC desc stuff on top of CompressedStream, we'd want such a cache.  Maybe some day.  Some one-element caches have the problem you point out, but if you look at the one-element cache for PC descs you'll see one with no such reported problems.  (IIRC I wrote both.)

> While you suggest 0 byte as synchronization markers, I've tried to synchronize the stream in #24713 and experiments have shown that while it improves things, it was not sufficient in my case. That's why I've abandoned that approach.

I looked at that code; thanks.  That wasn't what I meant.  The point of a null resynch byte is to allow *approximate* entry into the main stream.  It is an optional technique that would work like this:

 - The secondary index stores approximate address ranges, not exact byte pointers, to the data in the primary stream.
 - For example, for compactness, the secondary index might scale down by (say) 2 cache line sizes (discarding 7 lower bits).
 - As a tradeoff, this makes the secondary index smaller (discard 8 bits per entry).
 - But, it means you have a search a bit when you jump into the primary stream.
 - Since compressed data is not self-synchronizing, you have to first search for a null byte (after or maybe before).
 - The search starts just after a found null byte.
 - The length of the search is bounded by the scale factor (128 bytes, say).
 - The stream logic that traverses the CompressedStream tests for zero bytes and skips them (ignores them).

The thing to try first, though, is to store exact offsets into the secondary index.  Then you don't need to search, nor resynchronize, nor plant zero bytes in the stream.  Much simpler.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2896016101

From lmesnik at openjdk.org  Tue May 20 23:43:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 20 May 2025 23:43:52 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <iE96-C6XP0o8kEQfykentBlnj5GpJ3FYFonXs-WeFxc=.e49a9d22-caf3-4551-b943-7745ae91aeb4@github.com>

On Tue, 20 May 2025 19:33:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

Thanks, that's fine then.

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2896069990

From iklam at openjdk.org  Wed May 21 00:30:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 May 2025 00:30:52 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
Message-ID: <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>

On Tue, 20 May 2025 21:41:59 GMT, John R Rose <jrose at openjdk.org> wrote:

>> The problem is CDS; I have really started with `fast_compare()`, but after dehydration the pointers changed and the comparison did not work anymore. This is also a reason why I could not use the hashcode for the ordering.
>> If you'd prefer lexicographical sort (just a few extra lines) I could use that one...
>
> It's not good to introduce a new symbol comparator in a random place.  Symbol comparators should be defined and maintained centrally, in symbol.[ch]pp.
> 
> If there's a bug with fast_compare, I want us to fix it eventually.  So for now, define a companion function in symbol.hpp called fast_compare_cds_safe.  We can work with it from there.  You can use your proposed logic but we will probably want to fiddle with it, and probably merge it with fast_compare (per se) if CDS can be adjusted.

This problem should happen only with dynamic CDS archives.

With the static CDS archive (and AOT caches as well; `-XX:AOTCache` basically are static CDS archives), Symbols are copied into the archive while preserving the order of their relative addresses.

However, when creating a dynamic CDS archive, we first load a static archive. Let's say we load the static archive at address 0x800000000, a Symbol `A` in the static archive could have an address of `0x800001000`. Now, we load a class `K` who has a method named `B` but such a Symbol is not in the static archive, this Symbol will be dynamically allocated from the Metaspace. Since the address is decided by the OS, this symbol could have an address below the static archive. E.g., `0x700000000`;

Let's say `K` defines two methods, `A()` and `B()`, they are stored in the `InstanceKlass::_methods` array for `K`. This array is sorted by ascending addresses of the method's names. So `K::B()` comes before `K::A()`.

When `K` is copied into the dynamic archive, the symbol `B` will also be copied into the dynamic archive. The dynamic archive resides in a memory region above the static archive, so `B` will have an address like `0x800002000`. Therefore, we want the copy of `K` in the dynamic archive to have a `_methods` array where  `K::A()` comes before `K::B()`.

This is done in [`DynamicArchiveBuilder::sort_methods()`](https://github.com/openjdk/jdk/blob/cedd1a5343dceb5394b8ed5ea78bb717f05c8caf/src/hotspot/share/cds/dynamicArchive.cpp#L138)

My recommendation is to sort your table using `fast_compare()`, and re-sort this table in the same fashion as `DynamicArchiveBuilder::sort_methods()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2099077302

From duke at openjdk.org  Wed May 21 06:54:37 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 21 May 2025 06:54:37 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/b3ccffd7..5e1f9240

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04-05

  Stats: 51 lines in 3 files changed: 12 ins; 17 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Wed May 21 06:54:37 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 21 May 2025 06:54:37 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
 <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>
Message-ID: <o3w-RnUbz2C8b58KL9r6FYIyuo8tF-ohw7xoWO3xNtA=.3e35e598-533a-4a5a-b9c0-410e71eabd42@github.com>

On Thu, 15 May 2025 16:21:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused import
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73:
> 
>> 71:             return;
>> 72:         }
>> 73:         if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) {
> 
> Better to replace this with 
> `isContainerVersionSupported()`
> ...
> and implement all logic in the the ContainerRuntimeVersionTestUtils

created checkContainerVersionSupported()

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38:
> 
>> 36:     private final int micro;
>> 37:     private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0);
>> 38:     public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0);
> 
> Please add comment about meaning of the version or even better rename 
> DOCKER_MINIMAL_SUPPORTED_VERSION = ....

updated name to  DOCKER_MINIMAL_SUPPORTED_VERSION_CGROUPNS and PODMAN_MINIMAL_SUPPORTED_VERSION_CGROUPNS

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53:
> 
>> 51:         } else if (this.major < other.major) {
>> 52:             return -1;
>> 53:         } else { // equal major
> 
> no need to add `else {` here

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58:
> 
>> 56:             } else if (this.minor < other.minor) {
>> 57:                 return -1;
>> 58:             } else { // equal majors and minors
> 
> no need to add `else {` here

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81:
> 
>> 79:         } catch (Exception e) {
>> 80:             System.out.println("Failed to parse container runtime version: " + version);
>> 81:             return DEFAULT;
> 
> Any reason to don't fail here?

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94:
> 
>> 92:         } catch (Exception e) {
>> 93:             System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null");
>> 94:             return null;
> 
> Any reason to don't fail here?

updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494838
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099496846
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494004
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494142
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497419
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497254

From serb at openjdk.org  Wed May 21 09:00:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 09:00:56 GMT
Subject: Integrated: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c:
 enum type mismatch during build
In-Reply-To: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
References: <epqk1ls5KVTUITSA8N6y9PQ8x82lyUnLukqiKVy1v6I=.3e38b0d4-3802-4785-9921-21404368b518@github.com>
Message-ID: <eQyjt21uObP0Wx6HV6FFmndldoUbsvrc7AsTzuSoC2w=.92c21644-e898-46d6-b5a3-7aa448a1b3b5@github.com>

On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago).
> 
> I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases.
> 
> A proper fix (e.g., explicit type cast) may be introduced later if necessary.

This pull request has now been integrated.

Changeset: 5f38d1bb
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f38d1bb94d008c33c1a7af12c81ee0e15371e13
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25293

From ihse at openjdk.org  Wed May 21 09:22:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 May 2025 09:22:02 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <BVE7SlJ7Ek5rBk3QHLmBLSZLurkn3IbHy6cECNfcf4I=.e0b7f295-36a8-4006-9491-c531d293cab5@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

No, I'm sorry, I don't have the cycles over to drive such a thing. I appreciate the work you are doing but I am unable to help with anything apart from reviewing. So if you think you want to do this library by library, then do so, and if so keep this PR. Or maybe you can publish a PR that updates all libraries, and try to gather feedback from it. I don't know what's best.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2897228148

From rvansa at openjdk.org  Wed May 21 09:26:54 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 21 May 2025 09:26:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
 <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
Message-ID: <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>

On Wed, 21 May 2025 00:28:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It's not good to introduce a new symbol comparator in a random place.  Symbol comparators should be defined and maintained centrally, in symbol.[ch]pp.
>> 
>> If there's a bug with fast_compare, I want us to fix it eventually.  So for now, define a companion function in symbol.hpp called fast_compare_cds_safe.  We can work with it from there.  You can use your proposed logic but we will probably want to fiddle with it, and probably merge it with fast_compare (per se) if CDS can be adjusted.
>
> This problem should happen only with dynamic CDS archives.
> 
> With the static CDS archive (and AOT caches as well; `-XX:AOTCache` basically are static CDS archives), Symbols are copied into the archive while preserving the order of their relative addresses.
> 
> However, when creating a dynamic CDS archive, we first load a static archive. Let's say we load the static archive at address 0x800000000, a Symbol `A` in the static archive could have an address of `0x800001000`. Now, we load a class `K` who has a method named `B` but such a Symbol is not in the static archive, this Symbol will be dynamically allocated from the Metaspace. Since the address is decided by the OS, this symbol could have an address below the static archive. E.g., `0x700000000`;
> 
> Let's say `K` defines two methods, `A()` and `B()`, they are stored in the `InstanceKlass::_methods` array for `K`. This array is sorted by ascending addresses of the method's names. So `K::B()` comes before `K::A()`.
> 
> When `K` is copied into the dynamic archive, the symbol `B` will also be copied into the dynamic archive. The dynamic archive resides in a memory region above the static archive, so `B` will have an address like `0x800002000`. Therefore, we want the copy of `K` in the dynamic archive to have a `_methods` array where  `K::A()` comes before `K::B()`.
> 
> This is done in [`DynamicArchiveBuilder::sort_methods()`](https://github.com/openjdk/jdk/blob/cedd1a5343dceb5394b8ed5ea78bb717f05c8caf/src/hotspot/share/cds/dynamicArchive.cpp#L138)
> 
> My recommendation is to sort your table using `fast_compare()`, and re-sort this table in the same fashion as `DynamicArchiveBuilder::sort_methods()`.

Thanks for the pointers; in fact I had the problem with a (intermediate) variant that encoded the symbol addresses right into the stream. Therefore the issue was comparing value of symbol values before CDS persisting those and after dehydration. Since we're comparing only symbols within single class, I hope that the issue you describe above won't happen. I'll keep the problem with dynamic archives in mind, though.
With the current code I can try using `fast_compare` again and get back if I find any problems again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2099806937

From rvansa at openjdk.org  Wed May 21 11:34:36 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 21 May 2025 11:34:36 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v6]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <qPX52pFa9-qQj6p3NrhnmHqfMPwplB9wFaq_djGO06E=.23a57b6d-e4fd-4d3c-886f-4b9e59f74730@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Move search table into separate array
  
  * also drop custom symbol comparator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/148802fb..1806d022

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=04-05

  Stats: 257 lines in 15 files changed: 104 ins; 119 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From rvansa at openjdk.org  Wed May 21 12:07:57 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 21 May 2025 12:07:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
 <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
 <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
Message-ID: <om3aGzOSDh1EXnryHSzWRVa3d51b2UJ1oxBXP0i8Jro=.7eb182dd-ce6c-4ea2-aa43-ef52d0c495cd@github.com>

On Tue, 20 May 2025 23:01:08 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.
>> 
>> I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.
>> 
>> It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.
>> 
>> It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.
>> 
>> BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.
>> 
>> The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.
>> 
>> One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.
>> 
>> I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.
>
>> @rose00 While refactoring might be useful, this PR is trying to address a performance regression (in fact by improving the scenario significantly), and I'd prefer that to land in 25
> 
> It will land when it's ready.  It's not quite ready yet.  I'm not asking for reusability, but I am saying that doing a one-off index hack here is exchanging one kind of technical debt (maintenance complexity) for another (performance pothole).  If we hustle to make 25, we need a plan to fix it after 25.
> 
>> rather than to delay just for the sake of better 'reusability'.
> 
> Yes, 'reusability'.  That's how big systems are maintained.
> 
>> And TBH I don't consider binary search algorithm too difficult to validate.
> 
> TBH I do.  I've seen enough OBOEs for one lifetime.  I don't consider even that simple an algorithm to be fully tested unless it is either unit tested (gtest) or stress tested (threshold set small), and preferably both.  Testing it for just a few classes that have many fields is not full coverage.  (Normally for this kind of thing, your hard-coded constant 16 would be made a debug-only globals, and we'd stress-test with it set to 1 or 2.)   Writing a unit test requires enough factorization to write the unit test.  Which also tends towards virtuous reusability.
> 
>> While a simple cache might be useful, I don't have a good example to validate its usefulness. And turning a read-only scenario into mutating scenario can turn out badly for multithreaded code, as in https://bugs.openjdk.org/browse/JDK-8180450 .
> 
> No worries about this one; I'm not asking for such a thing, just noting in passing that it sometimes helps.  Probably not in this case, since you didn't resort the original array, and the usual sequential encounter order is direct, not requiring a cache.  If we were re-engineering PC desc stuff on top of CompressedStream, we'd want such a cache.  Maybe some day.  Some one-element caches have the problem you point out, but if you look at the one-element cache for PC descs you'll see one with no such reported problems.  (IIRC I wrote both.)
> 
>> While you suggest 0 byte as synchronization markers, I've tried to synchronize the stream in #24713 and experiments have shown that while it improves things, it was not sufficient in my case. That's why I've abandoned that approach.
> 
> I looked at that code; thanks.  That wasn't what I meant.  The point of a null resynch byte is to allow *approximate* entry into the main stream.  It is an optional technique that would work like this:
> 
>  ...

@rose00 I've applied your suggestion, moving the search table to a separate array. While I perceived keeping related data more together as a pro, this solution has a definite advantage that the implementation details for search table do not leak into Java code at all.

Should I turn the `SEARCH_TABLE_THRESHOLD` into global variable as you mention? It might offer an opportunity for fine-tuning. From testing point of view, it would scale the number of classes that have the search table attached; it won't change behaviour. If we're worried about off-by-one errors I would be rather concerned about the decisions on 1/2/3 byte encoding in the search table.

> It will land when it's ready. It's not quite ready yet. I'm not asking for reusability, but I am saying that doing a one-off index hack here is exchanging one kind of technical debt (maintenance complexity) for another (performance pothole). If we hustle to make 25, we need a plan to fix it after 25.

I am not trying to rush it, but keep a limited scope. Most importantly, I wanted to avoid making other parts of the codebase to reuse the implementation. From this point, I can imagine abstracting a bit more, if you find that useful, maybe at the cost of some virtual method calls.

> It is an optional technique that would work like this

Thanks for the explanation, I get it now. But yes, let's try to not complicate it now. There's no definite criteria how much CPU/memory tradeoff can JDK afford - that's also why this PR had several iterations. Initially I was looking for a solution consuming the fewest extra bytes, disregarding the expense of 'maintainability'.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2897709062

From rvansa at openjdk.org  Wed May 21 12:39:11 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 21 May 2025 12:39:11 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v7]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <0ukRXRaojw8KZXGYN_IpikqnA1kNsMoCWFE-0fOBHjk=.bda5ca70-ed55-4a27-a018-c89331415080@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/1806d022..fde66f35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/24847

From jsjolen at openjdk.org  Wed May 21 13:50:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 21 May 2025 13:50:56 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v3]
In-Reply-To: <t5VhAXldDRFdjJwHxcshgVbZJRZPqIOfB6Pb1fPSCSA=.dc93c458-4684-49c3-b936-9b57908b0373@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <t5VhAXldDRFdjJwHxcshgVbZJRZPqIOfB6Pb1fPSCSA=.dc93c458-4684-49c3-b936-9b57908b0373@github.com>
Message-ID: <En62x9xW_BhVdGV6d1NF5VctrMGYJZmy9MP85P0y_TU=.39dfe203-6cd5-4fa3-8d4c-a796ddcb52ee@github.com>

On Tue, 13 May 2025 14:20:48 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

All of this looks good to me.

It seems like there's no user-visible change, except the removal of the global variable. Is that correct?

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24872#pullrequestreview-2857814078

From rvansa at openjdk.org  Wed May 21 14:33:56 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 21 May 2025 14:33:56 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
 <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
 <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
Message-ID: <vsttNzJdwvD4ZRbhbv2yHoyWdfo15jG5GdhwmBR9qWE=.f38695a7-4d9c-4c3e-bbba-ff09f0f31067@github.com>

On Tue, 20 May 2025 23:01:08 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.
>> 
>> I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.
>> 
>> It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.
>> 
>> It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.
>> 
>> BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.
>> 
>> The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.
>> 
>> One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.
>> 
>> I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.
>
>> @rose00 While refactoring might be useful, this PR is trying to address a performance regression (in fact by improving the scenario significantly), and I'd prefer that to land in 25
> 
> It will land when it's ready.  It's not quite ready yet.  I'm not asking for reusability, but I am saying that doing a one-off index hack here is exchanging one kind of technical debt (maintenance complexity) for another (performance pothole).  If we hustle to make 25, we need a plan to fix it after 25.
> 
>> rather than to delay just for the sake of better 'reusability'.
> 
> Yes, 'reusability'.  That's how big systems are maintained.
> 
>> And TBH I don't consider binary search algorithm too difficult to validate.
> 
> TBH I do.  I've seen enough OBOEs for one lifetime.  I don't consider even that simple an algorithm to be fully tested unless it is either unit tested (gtest) or stress tested (threshold set small), and preferably both.  Testing it for just a few classes that have many fields is not full coverage.  (Normally for this kind of thing, your hard-coded constant 16 would be made a debug-only globals, and we'd stress-test with it set to 1 or 2.)   Writing a unit test requires enough factorization to write the unit test.  Which also tends towards virtuous reusability.
> 
>> While a simple cache might be useful, I don't have a good example to validate its usefulness. And turning a read-only scenario into mutating scenario can turn out badly for multithreaded code, as in https://bugs.openjdk.org/browse/JDK-8180450 .
> 
> No worries about this one; I'm not asking for such a thing, just noting in passing that it sometimes helps.  Probably not in this case, since you didn't resort the original array, and the usual sequential encounter order is direct, not requiring a cache.  If we were re-engineering PC desc stuff on top of CompressedStream, we'd want such a cache.  Maybe some day.  Some one-element caches have the problem you point out, but if you look at the one-element cache for PC descs you'll see one with no such reported problems.  (IIRC I wrote both.)
> 
>> While you suggest 0 byte as synchronization markers, I've tried to synchronize the stream in #24713 and experiments have shown that while it improves things, it was not sufficient in my case. That's why I've abandoned that approach.
> 
> I looked at that code; thanks.  That wasn't what I meant.  The point of a null resynch byte is to allow *approximate* entry into the main stream.  It is an optional technique that would work like this:
> 
>  ...

@rose00 I've attempted to extract the binary search in https://github.com/openjdk/jdk/commit/62a40f6b8aafb4a986add0bdac0425dfaf197d62 , but I am not convinced this is better.
The `SearchTable::lookup` is static now - I am not sure if I could have `class SearchTable: private Array<u1> { ... }` and have that allocated in metaspace...

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2898186528

From cjplummer at openjdk.org  Wed May 21 15:02:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 May 2025 15:02:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v7]
In-Reply-To: <0ukRXRaojw8KZXGYN_IpikqnA1kNsMoCWFE-0fOBHjk=.bda5ca70-ed55-4a27-a018-c89331415080@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <0ukRXRaojw8KZXGYN_IpikqnA1kNsMoCWFE-0fOBHjk=.bda5ca70-ed55-4a27-a018-c89331415080@github.com>
Message-ID: <oL0OKtZ9-6QOePFYXH_LgnRgWu4dp93oIl-35g_NvzE=.5f8d347a-8432-409a-ae23-4e69f7233d1c@github.com>

On Wed, 21 May 2025 12:39:11 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

It looks like you removed the SA changes, so I'm not so sure you still need a review from me. I just ask that you make sure the tests in serviceability/sa and sun/tools/jhsdb all pass. I'm about to be OOO for a week, so I won't be able to responds again until then.

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2858087019

From iklam at openjdk.org  Wed May 21 15:06:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 May 2025 15:06:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
 <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
 <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>
Message-ID: <WsMN_FOtF4desMyOyLVU6Y2l06AMjBJjB_mzY8pEcV0=.3262814d-6fd1-4624-b62f-af8af14b93f8@github.com>

On Wed, 21 May 2025 09:23:58 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This problem should happen only with dynamic CDS archives.
>> 
>> With the static CDS archive (and AOT caches as well; `-XX:AOTCache` basically are static CDS archives), Symbols are copied into the archive while preserving the order of their relative addresses.
>> 
>> However, when creating a dynamic CDS archive, we first load a static archive. Let's say we load the static archive at address 0x800000000, a Symbol `A` in the static archive could have an address of `0x800001000`. Now, we load a class `K` who has a method named `B` but such a Symbol is not in the static archive, this Symbol will be dynamically allocated from the Metaspace. Since the address is decided by the OS, this symbol could have an address below the static archive. E.g., `0x700000000`;
>> 
>> Let's say `K` defines two methods, `A()` and `B()`, they are stored in the `InstanceKlass::_methods` array for `K`. This array is sorted by ascending addresses of the method's names. So `K::B()` comes before `K::A()`.
>> 
>> When `K` is copied into the dynamic archive, the symbol `B` will also be copied into the dynamic archive. The dynamic archive resides in a memory region above the static archive, so `B` will have an address like `0x800002000`. Therefore, we want the copy of `K` in the dynamic archive to have a `_methods` array where  `K::A()` comes before `K::B()`.
>> 
>> This is done in [`DynamicArchiveBuilder::sort_methods()`](https://github.com/openjdk/jdk/blob/cedd1a5343dceb5394b8ed5ea78bb717f05c8caf/src/hotspot/share/cds/dynamicArchive.cpp#L138)
>> 
>> My recommendation is to sort your table using `fast_compare()`, and re-sort this table in the same fashion as `DynamicArchiveBuilder::sort_methods()`.
>
> Thanks for the pointers; in fact I had the problem with a (intermediate) variant that encoded the symbol addresses right into the stream. Therefore the issue was comparing value of symbol values before CDS persisting those and after dehydration. Since we're comparing only symbols within single class, I hope that the issue you describe above won't happen. I'll keep the problem with dynamic archives in mind, though.
> With the current code I can try using `fast_compare` again and get back if I find any problems again.

Even if the fields are only defined within the same class, the names of the fields are shared among different classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2100530720

From lmesnik at openjdk.org  Wed May 21 15:09:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 21 May 2025 15:09:55 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <4L78FN5dBp6so8QWalypTvm2lnXb9GU6zl3Hw6hK6Go=.26715817-5092-4489-ba9a-bf3a9800c478@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for fixing this!

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2858114150

From iklam at openjdk.org  Wed May 21 15:13:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 May 2025 15:13:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <WsMN_FOtF4desMyOyLVU6Y2l06AMjBJjB_mzY8pEcV0=.3262814d-6fd1-4624-b62f-af8af14b93f8@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
 <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
 <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>
 <WsMN_FOtF4desMyOyLVU6Y2l06AMjBJjB_mzY8pEcV0=.3262814d-6fd1-4624-b62f-af8af14b93f8@github.com>
Message-ID: <nwBD-hP6xDnLBSBRaOXEsgepX3KThDaDhhlTYyEdDtg=.1dd19a9f-1c02-44d5-926c-99308b81d96f@github.com>

On Wed, 21 May 2025 15:03:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thanks for the pointers; in fact I had the problem with a (intermediate) variant that encoded the symbol addresses right into the stream. Therefore the issue was comparing value of symbol values before CDS persisting those and after dehydration. Since we're comparing only symbols within single class, I hope that the issue you describe above won't happen. I'll keep the problem with dynamic archives in mind, though.
>> With the current code I can try using `fast_compare` again and get back if I find any problems again.
>
> Even if the fields are only defined within the same class, the names of the fields are shared among different classes.

To validate that you have sorted the table correctly, you should add a debug-only validation function. This function should be called after `set_fieldinfo_search_table()`, and also in `InstanceKlass::restore_unshareable_info()` and `InstanceKlass::remove_unshareable_info()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2100546703

From lfoltan at openjdk.org  Wed May 21 17:49:53 2025
From: lfoltan at openjdk.org (Lois Foltan)
Date: Wed, 21 May 2025 17:49:53 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <t1z-7-by5dWulfXM_FoPH8PksN6YqNpEzs5Dr0xUScw=.3a66db88-a4ed-44c3-ac17-da4b4c001227@github.com>

On Mon, 19 May 2025 07:35:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Overall looks good, a couple of comments below.

src/hotspot/share/oops/constantPool.hpp line 80:

> 78: };
> 79: 
> 80: class BSMAttributeEntry {

Please consider moving the description comment from lines #569-#572 ahead of this structure

src/hotspot/share/oops/constantPool.hpp line 92:

> 90:     return reinterpret_cast<u2*>(this + 1);
> 91:   }
> 92: 

Remove blank lines at #92, #95, #103

src/hotspot/share/oops/constantPool.hpp line 105:

> 103: 
> 104:   int argument_index(int n) const {
> 105:     assert(checked_cast<u2>(n) < _argument_count, "oob");

Should the assert contain a check that _argument_count is >= 0 as well?

src/hotspot/share/oops/constantPool.hpp line 638:

> 636:   u2 bootstrap_argument_count_at(int cp_index) {
> 637:     assert(tag_at(cp_index).has_bootstrap(), "Corrupted constant pool");
> 638:     int bsmai = bootstrap_methods_attribute_index(cp_index);

The "matched ending" assert was the only code that used bootstrap_operand_limit(), so that method could be removed as well.  This comment applies to bootstrap_operand_base() as well.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 124:

> 122:   private static long elementSize;
> 123: 
> 124:   private static int INDY_BSM_OFFSET = 0;

Please update the copyright of this file.

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

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2858597040
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2100820121
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2100820521
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2100831579
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2100833066
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2100849208

From amenkov at openjdk.org  Wed May 21 20:24:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 May 2025 20:24:33 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java times out
 after ClassNotFoundException
Message-ID: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>

The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
Now I cannot reproduce original test failure, so removing the test from problemlist

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/25366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357282
  Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25366/head:pull/25366

PR: https://git.openjdk.org/jdk/pull/25366

From mseledtsov at openjdk.org  Wed May 21 20:31:53 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 21 May 2025 20:31:53 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <-rGf3Cfj34SX1QlPIp1vyVRWGc67aFxFmbAqNC2iMyo=.d6eaa386-b98f-45e8-8035-94b5cf5f159a@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for the updates. Changes look good to me.

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

Marked as reviewed by mseledtsov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2859031087

From amenkov at openjdk.org  Wed May 21 20:39:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 May 2025 20:39:33 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
Message-ID: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>

The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.

Testing: new test, tier1 sanity run

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/25367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356222
  Stats: 125 lines in 4 files changed: 118 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25367/head:pull/25367

PR: https://git.openjdk.org/jdk/pull/25367

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

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

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

PR: https://git.openjdk.org/jdk/pull/25368

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

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

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From duke at openjdk.org  Thu May 22 03:56:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 03:56:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <KnZO7hSV3Uqtq6IdwySQL3u9siX_8SMxA3_MvxMsI2Y=.c57d5aae-e0ca-493b-ad7d-d57018a735da@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

@pawanchawdhary1 
Your change (at version 5e1f9240b379356fb8d5e0db1587216d1cbeed0f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2899823355

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From stefank at openjdk.org  Thu May 22 06:43:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 May 2025 06:43:02 GMT
Subject: Integrated: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <1K72xS65DDQdoYYsq8qF8jRD81puFZcvLijmNfze6GM=.e20e4213-17c9-48b3-bafe-0aba62b966af@github.com>

On Thu, 8 May 2025 10:01:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

This pull request has now been integrated.

Changeset: a919f6d0
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a919f6d04e5e1e3ccb123132ad945b240345dcaf
Stats:     229 lines in 15 files changed: 136 ins; 45 del; 48 mod

8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: sjohanss, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25114

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/25368

From jsikstro at openjdk.org  Thu May 22 08:01:01 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 22 May 2025 08:01:01 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
Message-ID: <3PWGWsTBWQcs_7hOuBg4oCJ9nunJsuUQrIxXX__5u6Q=.c4d7d011-eb14-477f-9cd8-d181f0037382@github.com>

On Thu, 15 May 2025 11:47:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update new order in tests

The CSR has now been approved. I'd say this is ready for review now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2900266756

From rvansa at openjdk.org  Thu May 22 08:21:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 22 May 2025 08:21:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Add search table validation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/fde66f35..1795e4b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=06-07

  Stats: 88 lines in 6 files changed: 60 ins; 16 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From rvansa at openjdk.org  Thu May 22 08:21:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 22 May 2025 08:21:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <nwBD-hP6xDnLBSBRaOXEsgepX3KThDaDhhlTYyEdDtg=.1dd19a9f-1c02-44d5-926c-99308b81d96f@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
 <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
 <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>
 <WsMN_FOtF4desMyOyLVU6Y2l06AMjBJjB_mzY8pEcV0=.3262814d-6fd1-4624-b62f-af8af14b93f8@github.com>
 <nwBD-hP6xDnLBSBRaOXEsgepX3KThDaDhhlTYyEdDtg=.1dd19a9f-1c02-44d5-926c-99308b81d96f@github.com>
Message-ID: <5hyI9wOvFD_3UZWLIK4YQKcDCR0By_1SRKK2DXFPVMs=.3f2c8b3e-d0cb-41f5-a324-bcadb9cd0bad@github.com>

On Wed, 21 May 2025 15:11:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Even if the fields are only defined within the same class, the names of the fields are shared among different classes.
>
> To validate that you have sorted the table correctly, you should add a debug-only validation function. This function should be called after `set_fieldinfo_search_table()`, and also in `InstanceKlass::restore_unshareable_info()` and `InstanceKlass::remove_unshareable_info()`.

Added, thanks for raising those places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2101937946

From stuefe at openjdk.org  Thu May 22 08:26:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 May 2025 08:26:54 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
Message-ID: <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>

On Thu, 15 May 2025 11:47:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update new order in tests

Metaspace changes (the few) seem fine. GC changes too.

Minor remarks inline

src/hotspot/share/memory/metaspace/metaspaceDCmd.cpp line 62:

> 60: void MetaspaceDCmd::execute(DCmdSource source, TRAPS) {
> 61:   MetaspaceUtils::print_on(output());
> 62: 

Okay, though arguably somewhat redundant with the following output

test/hotspot/jtreg/serviceability/dcmd/gc/HeapInfoTest.java line 48:

> 46:         OutputAnalyzer output = executor.execute(cmd);
> 47:         output.shouldNotContain("Unknown diagnostic command");
> 48:         output.shouldHaveExitValue(0);

This was already kind of weak before and is almost useless now :) can we improve on that? A command reporting back nothing would now result in a green test?

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

PR Review: https://git.openjdk.org/jdk/pull/25214#pullrequestreview-2860244469
PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2101938786
PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2101933679

From jsikstro at openjdk.org  Thu May 22 08:51:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 22 May 2025 08:51:52 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
 <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>
Message-ID: <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>

On Thu, 22 May 2025 08:19:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update new order in tests
>
> src/hotspot/share/memory/metaspace/metaspaceDCmd.cpp line 62:
> 
>> 60: void MetaspaceDCmd::execute(DCmdSource source, TRAPS) {
>> 61:   MetaspaceUtils::print_on(output());
>> 62: 
> 
> Okay, though arguably somewhat redundant with the following output

Sure. Should I revert adding this line, leaving the Metaspace jcmd unchanged?

> test/hotspot/jtreg/serviceability/dcmd/gc/HeapInfoTest.java line 48:
> 
>> 46:         OutputAnalyzer output = executor.execute(cmd);
>> 47:         output.shouldNotContain("Unknown diagnostic command");
>> 48:         output.shouldHaveExitValue(0);
> 
> This was already kind of weak before and is almost useless now :) can we improve on that? A command reporting back nothing would now result in a green test?

I agree. It's hard to grep for specific information since most GC have different approaches to printing similar information.

However, all GCs (even Epsilon) print the string "used", so maybe grepping for that is a reasonable approach, just to see that something is printed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2101998172
PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2102001583

From dholmes at openjdk.org  Thu May 22 09:46:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 May 2025 09:46:50 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <408vpILn_Eas8VnIfqNEhRLvdp0KPRaFDztZ0M0GyK0=.d13cf2f0-8c09-459a-b504-e13ac6669072@github.com>

On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

At the moment class initialization in a vthread pins the carrier so I'm not sure why this is considered a problem??

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

PR Comment: https://git.openjdk.org/jdk/pull/25367#issuecomment-2900578872

From alanb at openjdk.org  Thu May 22 10:06:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 10:06:50 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <408vpILn_Eas8VnIfqNEhRLvdp0KPRaFDztZ0M0GyK0=.d13cf2f0-8c09-459a-b504-e13ac6669072@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
 <408vpILn_Eas8VnIfqNEhRLvdp0KPRaFDztZ0M0GyK0=.d13cf2f0-8c09-459a-b504-e13ac6669072@github.com>
Message-ID: <fyyKcX9-NSI4SFEudBE4ZreJ-yORV2jpTMvMeNcgW1I=.6ec60145-2b0b-462c-85ed-2ca389c1195b@github.com>

On Thu, 22 May 2025 09:44:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> At the moment class initialization in a vthread pins the carrier so I'm not sure why this is considered a problem??

The output is confusing as it prints the "waiting on the Class initialization monitor for XXX" twice. It makes it looks like the carrier is blocked in java.lang.VirtualThread.runContinuation is waiting for XXX to be initialized. So I think we should fix this, only print the "waiting on Class .." line once, and in the virtual thread stack trace as that it is thread that is really waiting.

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

PR Comment: https://git.openjdk.org/jdk/pull/25367#issuecomment-2900639175

From shade at openjdk.org  Thu May 22 10:40:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 10:40:00 GMT
Subject: RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental) [v3]
In-Reply-To: <vi1b4ZQMnv0D_EY87SHq8QLMXkjAgrGPuuKpELiZGms=.b862565e-7a27-47f1-8dde-9b2435332753@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <vi1b4ZQMnv0D_EY87SHq8QLMXkjAgrGPuuKpELiZGms=.b862565e-7a27-47f1-8dde-9b2435332753@github.com>
Message-ID: <LOXIxlt9XOdrNo-omVJqaHe9gOdfqPlyX2DQvEN1_Qo=.c385d8fe-0169-4090-ae86-f942018376ba@github.com>

On Mon, 19 May 2025 17:06:09 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests

You need to make a JEP sub-task and put the PR under it. Bots would rightfully disallow PRs for the root JEP issue :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2900736851

From dholmes at openjdk.org  Thu May 22 12:00:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 May 2025 12:00:56 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <ZRHU_8xy9WeqVOLQlF-8ccjzJSkwuXNyO5nbH0Vf5mg=.408258c6-cfa2-45c5-be4c-36924f3dd3e9@github.com>

On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

To me, in the pinned case, both threads are "really waiting". The carrier physically and the vthread "logically". This also indicates it is actually doing pinning.

Once we get non-pinning class init it should just show up on the vthread as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/25367#issuecomment-2900968461

From alanb at openjdk.org  Thu May 22 12:17:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 12:17:51 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <ZRHU_8xy9WeqVOLQlF-8ccjzJSkwuXNyO5nbH0Vf5mg=.408258c6-cfa2-45c5-be4c-36924f3dd3e9@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
 <ZRHU_8xy9WeqVOLQlF-8ccjzJSkwuXNyO5nbH0Vf5mg=.408258c6-cfa2-45c5-be4c-36924f3dd3e9@github.com>
Message-ID: <wFpJQ87jUoK42HdQlkjZ3MoYaz1cz41NXawe7WxCcpg=.8416bf91-77d1-4b8a-8696-f83f5c19b56f@github.com>

On Thu, 22 May 2025 11:58:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To me, in the pinned case, both threads are "really waiting". The carrier physically and the vthread "logically". This also indicates it is actually doing pinning.

The intended mental model has always been that the carrier is waiting for the virtual thread. The virtual thread may be blocked and waiting for something else of course. This is why, for example, ThreadMXBean and ThreadInfo::getLockedMonitors() with the ID of carrier report the identity hash of the virtual thread when there is a virtual thread mounted. There is some outstanding work on the thread state reported for carriers but once that is done then it will be much clearer.

There are changes in the loom repo to allow preemption when waiting for a class to be initialized. In that case, the virtual thread will unmount so it won't appear in the HotSpot VM thread dump. However, if pinned, then it will appear and we will get the same confusing output. So I think we should fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25367#issuecomment-2901014409

From cnorrbin at openjdk.org  Thu May 22 14:09:37 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 22 May 2025 14:09:37 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
Message-ID: <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>

> Hi everyone,
> 
> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
> 
> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
> 
> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.

Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into statsampler-removal
 - removed last traces of hrt.ticks
 - Merge branch 'master' into statsampler-removal
 - feedback fixes
 - removed the PerfDataSamplingInterval flag
 - calculate timestamp in jstat instead of sampling
 - StatSampler + sampling code removed

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

Changes: https://git.openjdk.org/jdk/pull/24872/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24872&range=03
  Stats: 864 lines in 25 files changed: 150 ins; 655 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/24872.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24872/head:pull/24872

PR: https://git.openjdk.org/jdk/pull/24872

From cnorrbin at openjdk.org  Thu May 22 14:14:52 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 22 May 2025 14:14:52 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v3]
In-Reply-To: <En62x9xW_BhVdGV6d1NF5VctrMGYJZmy9MP85P0y_TU=.39dfe203-6cd5-4fa3-8d4c-a796ddcb52ee@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <t5VhAXldDRFdjJwHxcshgVbZJRZPqIOfB6Pb1fPSCSA=.dc93c458-4684-49c3-b936-9b57908b0373@github.com>
 <En62x9xW_BhVdGV6d1NF5VctrMGYJZmy9MP85P0y_TU=.39dfe203-6cd5-4fa3-8d4c-a796ddcb52ee@github.com>
Message-ID: <qCARRNDtoHzlxoco3Nc2RzcaBYZcXWDxHNCVRfjG0VE=.e5caa003-bb0f-41f3-91fc-a5b2f9c59363@github.com>

On Wed, 21 May 2025 13:48:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> It seems like there's no user-visible change, except the removal of the global variable. Is that correct?

Besides the global variable, there's a slight change in the behaviour of the perfdata-counters for Serial/Parallel, as mentioned in the PR. The JBS issue has a clarifying comment explaining why this shouldn't have any meaningful impact.

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

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2901383778

From duke at openjdk.org  Thu May 22 17:11:08 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 22 May 2025 17:11:08 GMT
Subject: Integrated: 8352926: New test TestDockerMemoryMetricsSubgroup.java
 fails
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <wSvW08imr32VkbgOIHKZlckjkOedt3NrD-xZYEdbe5Y=.0f593375-80bc-416a-8fc4-a39dbf114db0@github.com>

On Tue, 29 Apr 2025 13:04:15 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

This pull request has now been integrated.

Changeset: 9ca1004e
Author:    pawan chawdhary <pawan at dhcp-10-48-118-86.wifi.oracle.com>
Committer: Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ca1004e76a614328cd2eb7546143839c4d2f810
Stats:     118 lines in 3 files changed: 115 ins; 3 del; 0 mod

8352926: New test TestDockerMemoryMetricsSubgroup.java fails

Reviewed-by: mseledtsov, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/24948

From jsjolen at openjdk.org  Thu May 22 17:55:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 22 May 2025 17:55:07 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Lois's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/e10d91a5..13e27259

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

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

PR: https://git.openjdk.org/jdk/pull/25298

From jsjolen at openjdk.org  Thu May 22 17:55:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 22 May 2025 17:55:07 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
Message-ID: <8Kl9attQHg4AjbIm2DsvPGVBnzrFd6laBwILosuBjHU=.dbdb3e09-70a5-44a3-8615-4374fbcff0fc@github.com>

On Thu, 22 May 2025 17:52:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lois's comments

Thank you for the review Lois! I've addressed most of your comments, but I didn't add any documentation for the `BSMAttributeEntry` (yet).

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

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2862094950

From jsjolen at openjdk.org  Thu May 22 17:55:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 22 May 2025 17:55:08 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <t1z-7-by5dWulfXM_FoPH8PksN6YqNpEzs5Dr0xUScw=.3a66db88-a4ed-44c3-ac17-da4b4c001227@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <t1z-7-by5dWulfXM_FoPH8PksN6YqNpEzs5Dr0xUScw=.3a66db88-a4ed-44c3-ac17-da4b4c001227@github.com>
Message-ID: <TdBL5-lg_ojiQ1hV8h-biSD8YNdNolzz-k0qwjiigKA=.5f933a82-e36a-4761-b2da-cab7ef69ac45@github.com>

On Wed, 21 May 2025 17:28:12 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lois's comments
>
> src/hotspot/share/oops/constantPool.hpp line 80:
> 
>> 78: };
>> 79: 
>> 80: class BSMAttributeEntry {
> 
> Please consider moving the description comment from lines #569-#572 ahead of this structure

This?


  // The first part of the operands array consists of an index into the second part.
  // Extract a 32-bit index value from the first part.


Wouldn't it be better to leave it where it is, but add a comment ahead of the structure?

> src/hotspot/share/oops/constantPool.hpp line 92:
> 
>> 90:     return reinterpret_cast<u2*>(this + 1);
>> 91:   }
>> 92: 
> 
> Remove blank lines at #92, #95, #103

We typically keep a space before we change access modifier, let's keep that pattern in here. We can tighten up the rest of the code according to your suggestions, however.

> src/hotspot/share/oops/constantPool.hpp line 105:
> 
>> 103: 
>> 104:   int argument_index(int n) const {
>> 105:     assert(checked_cast<u2>(n) < _argument_count, "oob");
> 
> Should the assert contain a check that _argument_count is >= 0 as well?

I don't think so, it's a `u2` so that's just part of its type.

> src/hotspot/share/oops/constantPool.hpp line 638:
> 
>> 636:   u2 bootstrap_argument_count_at(int cp_index) {
>> 637:     assert(tag_at(cp_index).has_bootstrap(), "Corrupted constant pool");
>> 638:     int bsmai = bootstrap_methods_attribute_index(cp_index);
> 
> The "matched ending" assert was the only code that used bootstrap_operand_limit(), so that method could be removed as well.  This comment applies to bootstrap_operand_base() as well.

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2103107280
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2103101655
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2103103526
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2103104346

From jsikstro at openjdk.org  Thu May 22 19:49:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 22 May 2025 19:49:17 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v5]
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <WE2KdgDnKo_otVpnOILVQUjqeOFEKbctYmsAeXwUP_M=.b7b086ee-5cc6-44ff-96e0-fe3b580b2ca8@github.com>

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

Joel Sikstr?m has updated the pull request incrementally with four additional commits since the last revision:

 - Feedback on Metaspace jcmd
 - Copyright years
 - Make HeapInfoTest.java more robust
 - Switch naming order of ring-buffer names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25214/files
  - new: https://git.openjdk.org/jdk/pull/25214/files/689a2230..60c5b606

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=03-04

  Stats: 21 lines in 5 files changed: 7 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25214/head:pull/25214

PR: https://git.openjdk.org/jdk/pull/25214

From jsikstro at openjdk.org  Thu May 22 19:49:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 22 May 2025 19:49:17 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
Message-ID: <6IZ5ldgwmNwRUkmLsCLCEjdvruFE1g73JUxql0Jx8jo=.b91e7e28-9555-41a5-b482-4aa5a257e4d0@github.com>

On Thu, 15 May 2025 11:47:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update new order in tests

I fixed some offline feedback from @stefank on naming and addressed feedback from @tstuefe in new commits.

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2902380574

From lmesnik at openjdk.org  Thu May 22 19:54:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 22 May 2025 19:54:55 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java times out
 after ClassNotFoundException
In-Reply-To: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
Message-ID: <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>

On Wed, 21 May 2025 20:17:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
> Now I cannot reproduce original test failure, so removing the test from problemlist

As I understand, this fix is not related to timeout. So test is going to fail. It might be makes a sense to remove it from problemlist to see how it works. However better to rename PR summary.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/share/aod/AODRunnerArgParser.java line 109:

> 107:         }
> 108: 
> 109:         String target = options.getProperty(TARGET_APP_PARAM);

I think it is better to remove -classPath from parameters and 
use
 ${test.class.path}
directly in the test.

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

PR Review: https://git.openjdk.org/jdk/pull/25366#pullrequestreview-2862411340
PR Review: https://git.openjdk.org/jdk/pull/25366#pullrequestreview-2862413634
PR Review Comment: https://git.openjdk.org/jdk/pull/25366#discussion_r2103297797

From iveresov at openjdk.org  Thu May 22 20:25:21 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 22 May 2025 20:25:21 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v23]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <Ig2sBzRGA8Ki0S1uKrzGKuP7nPqXwVP2r7iudXwyXyo=.2d60a85e-7994-4326-8533-006f4356c453@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:

 - Merge branch 'master' into pp2
 - Merge branch 'master' into pp2
 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform
 - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
   
   Reviewed-by: vlivanov, kvn
 - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing
   
   Reviewed-by: naoto
 - ... and 78 more: https://git.openjdk.org/jdk/compare/139a05d0...7a350671

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22
  Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From amenkov at openjdk.org  Thu May 22 20:35:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 May 2025 20:35:51 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
Message-ID: <HRWYSNTi9R5lklps1beu8-YIG32Nn0exZChYZ2WCmKY=.43552377-65be-4490-9157-9149f4ace627@github.com>

On Thu, 22 May 2025 19:50:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> As I understand, this fix is not related to timeout. So test is going to fail. It might be makes a sense to remove it from problemlist to see how it works. However better to rename PR summary.

Oh, right. It's socket timeout, not the test timeout. Renamed JBS issue

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2902499989

From amenkov at openjdk.org  Thu May 22 20:40:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 May 2025 20:40:52 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
Message-ID: <oENmA52HeEClkIv0vkK0OeyVpMEP8uZJCD2WivLm3a8=.74a971c9-8464-4e39-9241-570e18f8a93a@github.com>

On Thu, 22 May 2025 19:51:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
>> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
>> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
>> Now I cannot reproduce original test failure, so removing the test from problemlist
>
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/AODRunnerArgParser.java line 109:
> 
>> 107:         }
>> 108: 
>> 109:         String target = options.getProperty(TARGET_APP_PARAM);
> 
> I think it is better to remove -classPath from parameters and 
> use
>  ${test.class.path}
> directly in the test.

The test is run by `nsk.share.aod.AODTestRunner` which runs test app specified by "target" argument.
Target apps have no system properties like test.class.path

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25366#discussion_r2103363348

From prr at openjdk.org  Thu May 22 21:34:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:34:50 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zS5WZR4Cen8tmwZk_Y4kSHU3wpLpMysoCv5WfF4yRUM=.4c035191-6fb5-46f2-ab11-f35701183529@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Just speaking for the one client demo.
Someone else will need to review the other 98% of this PR

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2862613813

From iveresov at openjdk.org  Fri May 23 02:54:55 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 23 May 2025 02:54:55 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v24]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <HK2Pc2880mYO2720j676ZquD17FhNBaFReq_mSiZTx0=.b99b884e-7a50-4747-b2b1-443362defc38@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Missing part of the merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/7a350671..a1958ece

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22-23

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

PR: https://git.openjdk.org/jdk/pull/24886

From duke at openjdk.org  Fri May 23 04:33:36 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 23 May 2025 04:33:36 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v3]
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

PAWAN CHAWDHARY has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8354475
 - Update TestDockerMemoryMetricsSubgroup.java
   
   remove extra space
 - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

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

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

PR: https://git.openjdk.org/jdk/pull/24930

From stuefe at openjdk.org  Fri May 23 04:33:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 May 2025 04:33:57 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
 <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>
 <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>
Message-ID: <8EPYeJoeysrxsu4xgcisxF3PDL0NiqmdzYdhmLwtsZI=.cba6e5f6-4f4e-4fd2-9497-7c9f2e4d4bd2@github.com>

On Thu, 22 May 2025 08:46:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace/metaspaceDCmd.cpp line 62:
>> 
>>> 60: void MetaspaceDCmd::execute(DCmdSource source, TRAPS) {
>>> 61:   MetaspaceUtils::print_on(output());
>>> 62: 
>> 
>> Okay, though arguably somewhat redundant with the following output
>
> Sure. Should I revert adding this line, leaving the Metaspace jcmd unchanged?

No, on second thought it is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2103779705

From stuefe at openjdk.org  Fri May 23 04:38:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 May 2025 04:38:57 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v5]
In-Reply-To: <WE2KdgDnKo_otVpnOILVQUjqeOFEKbctYmsAeXwUP_M=.b7b086ee-5cc6-44ff-96e0-fe3b580b2ca8@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <WE2KdgDnKo_otVpnOILVQUjqeOFEKbctYmsAeXwUP_M=.b7b086ee-5cc6-44ff-96e0-fe3b580b2ca8@github.com>
Message-ID: <mTuJ6-rrpsc81IYMSZ7r3bPpNZwkccjojFDnrchjDnI=.ef855079-34f1-498d-ac9e-43bc95246b6f@github.com>

On Thu, 22 May 2025 19:49:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Feedback on Metaspace jcmd
>  - Copyright years
>  - Make HeapInfoTest.java more robust
>  - Switch naming order of ring-buffer names

Marked as reviewed by stuefe (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25214#pullrequestreview-2863132900

From stuefe at openjdk.org  Fri May 23 04:38:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 May 2025 04:38:58 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
 <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>
 <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>
Message-ID: <OYWQbXybQ6SRpeFCxAeP0LsNAXQ0KBZD2cqpKgnue6s=.ece3aa1d-9114-4b5b-a6ae-9133585063b3@github.com>

On Thu, 22 May 2025 08:48:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/dcmd/gc/HeapInfoTest.java line 48:
>> 
>>> 46:         OutputAnalyzer output = executor.execute(cmd);
>>> 47:         output.shouldNotContain("Unknown diagnostic command");
>>> 48:         output.shouldHaveExitValue(0);
>> 
>> This was already kind of weak before and is almost useless now :) can we improve on that? A command reporting back nothing would now result in a green test?
>
> I agree. It's hard to grep for specific information since most GC have different approaches to printing similar information.
> 
> However, all GCs (even Epsilon) print the string "used", so maybe grepping for that is a reasonable approach, just to see that something is printed?

Heap.info is important; we should have better tests for this. But we can hold this off for a separate PR, so I am fine with scanning for "used".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2103784060

From jsikstro at openjdk.org  Fri May 23 06:48:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 23 May 2025 06:48:31 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v6]
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <sN4KakPeCfT7R8Usm-D4L0Q6cY_3s6wWwC-5wyrKte0=.1ea07bef-b88d-4895-83c3-3ef339bce3ff@github.com>

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Add back MetaspaceUtils::print_on() in Metaspace jcmd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25214/files
  - new: https://git.openjdk.org/jdk/pull/25214/files/60c5b606..b54ebc02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/25214

From ayang at openjdk.org  Fri May 23 08:28:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 23 May 2025 08:28:16 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v5]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <zPyPgjQROLoTEs5LwLb91-B3Q_Fe6WXPGiZyKOXC4DI=.67847276-ab90-4a9e-bb00-98cc983ff855@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/e39ece09..320e590b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=03-04

  Stats: 47415 lines in 735 files changed: 32367 ins; 11142 del; 3906 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From stefank at openjdk.org  Fri May 23 10:13:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 May 2025 10:13:52 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v6]
In-Reply-To: <sN4KakPeCfT7R8Usm-D4L0Q6cY_3s6wWwC-5wyrKte0=.1ea07bef-b88d-4895-83c3-3ef339bce3ff@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <sN4KakPeCfT7R8Usm-D4L0Q6cY_3s6wWwC-5wyrKte0=.1ea07bef-b88d-4895-83c3-3ef339bce3ff@github.com>
Message-ID: <5Om_Z03KbgSpEbB4U4ZnzOL2TWA_nrfMmgmRlGpAJ1c=.50e48d0c-ae93-4ec8-982b-b757c7b8f95a@github.com>

On Fri, 23 May 2025 06:48:31 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back MetaspaceUtils::print_on() in Metaspace jcmd

This looks good to me! I added a small nit.

src/hotspot/share/gc/shared/collectedHeap.hpp line 55:

> 53: class GCHeapLog;
> 54: class MemoryPool;
> 55: class GCMetaspaceLog;

Sort these

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25214#pullrequestreview-2863925232
PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2104275736

From jsikstro at openjdk.org  Fri May 23 10:47:37 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 23 May 2025 10:47:37 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v7]
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <8dQ4VQlJ3ZBdMZJnq43HeBRLRiqOutWvvxvOccMAtNY=.403da2ad-8b0b-460a-b71c-4fb628b8aeaa@github.com>

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Sort forward declarations in collectedHeap.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25214/files
  - new: https://git.openjdk.org/jdk/pull/25214/files/b54ebc02..cd326c2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25214&range=05-06

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25214/head:pull/25214

PR: https://git.openjdk.org/jdk/pull/25214

From jsikstro at openjdk.org  Fri May 23 10:47:37 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 23 May 2025 10:47:37 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v6]
In-Reply-To: <5Om_Z03KbgSpEbB4U4ZnzOL2TWA_nrfMmgmRlGpAJ1c=.50e48d0c-ae93-4ec8-982b-b757c7b8f95a@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <sN4KakPeCfT7R8Usm-D4L0Q6cY_3s6wWwC-5wyrKte0=.1ea07bef-b88d-4895-83c3-3ef339bce3ff@github.com>
 <5Om_Z03KbgSpEbB4U4ZnzOL2TWA_nrfMmgmRlGpAJ1c=.50e48d0c-ae93-4ec8-982b-b757c7b8f95a@github.com>
Message-ID: <GZYJ370iK-immMQdIHANtHmW6upyBdOCm0YEyKTcslQ=.6cbbaba5-e31f-43d3-ba17-3c458275ed1f@github.com>

On Fri, 23 May 2025 10:11:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back MetaspaceUtils::print_on() in Metaspace jcmd
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 55:
> 
>> 53: class GCHeapLog;
>> 54: class MemoryPool;
>> 55: class GCMetaspaceLog;
> 
> Sort these

Fixed. I weant ahead and sorted GCMemoryManager as well, which is now in the right alphabetically-ordered place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2104326038

From stefank at openjdk.org  Fri May 23 10:49:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 May 2025 10:49:56 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v7]
In-Reply-To: <8dQ4VQlJ3ZBdMZJnq43HeBRLRiqOutWvvxvOccMAtNY=.403da2ad-8b0b-460a-b71c-4fb628b8aeaa@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <8dQ4VQlJ3ZBdMZJnq43HeBRLRiqOutWvvxvOccMAtNY=.403da2ad-8b0b-460a-b71c-4fb628b8aeaa@github.com>
Message-ID: <UTMNhyCzOAg9aGwqkLjS7uVIThOwCOiAOvmldkJfHXU=.07a3b700-b111-41dd-aeec-2c6714a947b8@github.com>

On Fri, 23 May 2025 10:47:37 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
>> 
>> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
>> 
>> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
>> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
>> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
>> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
>> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
>> 
>> Testing:
>> * GHA, Oracle's tier 1-4
>> * Manuel inspection of printed content
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort forward declarations in collectedHeap.hpp

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25214#pullrequestreview-2864009659

From jsikstro at openjdk.org  Fri May 23 12:32:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 23 May 2025 12:32:53 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v4]
In-Reply-To: <OYWQbXybQ6SRpeFCxAeP0LsNAXQ0KBZD2cqpKgnue6s=.ece3aa1d-9114-4b5b-a6ae-9133585063b3@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <R9Wi-syY7gZ2Kd555f3T1J33OPqP6OwQi6QIxSTBqDM=.07e47d10-bd15-4a55-810e-204c6fe7ce5a@github.com>
 <7EztCfjwj8KrtUzBxNcIQOGccgfCh6DcKE9143ZoYis=.7ed24333-6ef0-43c1-8d99-482f6a845600@github.com>
 <ROfotMydl1qdqK-TpncxP6-wtFPaXQHJnPwd8iC99y8=.13a347cf-4de7-4d66-a39c-ccd7f990431e@github.com>
 <OYWQbXybQ6SRpeFCxAeP0LsNAXQ0KBZD2cqpKgnue6s=.ece3aa1d-9114-4b5b-a6ae-9133585063b3@github.com>
Message-ID: <MCzHl_vKn171XlXgqZBJIL1SUckQTvzL6w7qJaV8rCw=.ee980e77-1fff-48c3-b256-8f53fec5fbcb@github.com>

On Fri, 23 May 2025 04:36:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I agree. It's hard to grep for specific information since most GC have different approaches to printing similar information.
>> 
>> However, all GCs (even Epsilon) print the string "used", so maybe grepping for that is a reasonable approach, just to see that something is printed?
>
> Heap.info is important; we should have better tests for this. But we can hold this off for a separate PR, so I am fine with scanning for "used".

I agree that the test should be improved. I'll file an issue once this PR is integrated to follow up on that.

Maybe some inspiration can be taken from the SA test in `test/hotspot/jtreg/serviceability/sa/TestUniverse.java`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25214#discussion_r2104489194

From jbechberger at openjdk.org  Fri May 23 16:37:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 23 May 2025 16:37:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v4]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <0wCu17xvBIjYJZnYLT90XFzsmQ-PY3WUyJw3e4nBBIo=.10693121-d72e-43df-88c5-6038f32ec4b1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'pr/24296' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix tests
 - Remove unused WhiteBox method
 - Read _active_signal_handlers atomically
 - Check whether raw_thread is not null and is JavaThread is signal handler
 - Tiny fixes
 - Fix uninitialized variable
 - Reduce diff
 - Refactor
 - Reduce diff
 - ... and 13 more: https://git.openjdk.org/jdk/compare/1cf582a0...eaca165d

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=03
  Stats: 2342 lines in 46 files changed: 2191 ins; 130 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From sspitsyn at openjdk.org  Fri May 23 17:22:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 17:22:52 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <HRWYSNTi9R5lklps1beu8-YIG32Nn0exZChYZ2WCmKY=.43552377-65be-4490-9157-9149f4ace627@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
 <HRWYSNTi9R5lklps1beu8-YIG32Nn0exZChYZ2WCmKY=.43552377-65be-4490-9157-9149f4ace627@github.com>
Message-ID: <zpGLP2ieEV1zyQqtos0X7CkLzEsIAAie_a7qhFdzbVE=.dcc592ba-6c0b-412c-b27c-1f987f936685@github.com>

On Thu, 22 May 2025 20:33:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Oh, right. It's socket timeout, not the test timeout. Renamed JBS issue

Nit: Would it better to replace: "fails after ClassNotFoundException" => "fails with ClassNotFoundException" ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2905199223

From sspitsyn at openjdk.org  Fri May 23 17:28:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 17:28:53 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
Message-ID: <pkAJyVThxAqr3_h4foYeXbWhXqPci5SMMfirczmJ5yI=.740f7d05-c6ae-4947-a014-48debfde7ff8@github.com>

On Wed, 21 May 2025 20:17:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
> Now I cannot reproduce original test failure, so removing the test from problemlist

This test was marked in ProblemList with https://bugs.openjdk.org/browse/JDK-8202971.
Does removing it from ProblemList mean the test does not fail with the symptom of 8202971 anymore?

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2905224802

From amenkov at openjdk.org  Fri May 23 17:56:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 May 2025 17:56:51 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <zpGLP2ieEV1zyQqtos0X7CkLzEsIAAie_a7qhFdzbVE=.dcc592ba-6c0b-412c-b27c-1f987f936685@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
 <HRWYSNTi9R5lklps1beu8-YIG32Nn0exZChYZ2WCmKY=.43552377-65be-4490-9157-9149f4ace627@github.com>
 <zpGLP2ieEV1zyQqtos0X7CkLzEsIAAie_a7qhFdzbVE=.dcc592ba-6c0b-412c-b27c-1f987f936685@github.com>
Message-ID: <fiQeZFSun6nbYvl1Y1-QyE_1zRvdW4Rv88pRF9XaQb4=.35940454-eb4b-4ced-aa79-23b8ee2023cf@github.com>

On Fri, 23 May 2025 17:19:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Oh, right. It's socket timeout, not the test timeout. Renamed JBS issue
> 
> Nit: Would it better to replace: "fails after ClassNotFoundException" => "fails with ClassNotFoundException" ?

Actually It fails with SocketTimeoutException. The test waits target process to connect, but it happens after target app fails with ClassNotFoundException

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2905345767

From amenkov at openjdk.org  Fri May 23 17:56:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 May 2025 17:56:52 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <pkAJyVThxAqr3_h4foYeXbWhXqPci5SMMfirczmJ5yI=.740f7d05-c6ae-4947-a014-48debfde7ff8@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <pkAJyVThxAqr3_h4foYeXbWhXqPci5SMMfirczmJ5yI=.740f7d05-c6ae-4947-a014-48debfde7ff8@github.com>
Message-ID: <7vlGRl7DWdAWWyGZCfls4MxuTyDZIWMUH85dUtZdvaU=.52a17463-91f1-43a4-924b-25bc60229b94@github.com>

On Fri, 23 May 2025 17:26:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This test was marked in ProblemList with https://bugs.openjdk.org/browse/JDK-8202971. The test was intermittently failing with timeouts in JDK 11. Does removing it from ProblemList mean the test does not fail with the symptom of 8202971 anymore? I'm double-checking because I'm not sure I fully understand the PR description.

I was not able to reproduce 8202971 (400 runs)

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2905352810

From sspitsyn at openjdk.org  Fri May 23 18:33:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 18:33:53 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <fiQeZFSun6nbYvl1Y1-QyE_1zRvdW4Rv88pRF9XaQb4=.35940454-eb4b-4ced-aa79-23b8ee2023cf@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
 <HRWYSNTi9R5lklps1beu8-YIG32Nn0exZChYZ2WCmKY=.43552377-65be-4490-9157-9149f4ace627@github.com>
 <zpGLP2ieEV1zyQqtos0X7CkLzEsIAAie_a7qhFdzbVE=.dcc592ba-6c0b-412c-b27c-1f987f936685@github.com>
 <fiQeZFSun6nbYvl1Y1-QyE_1zRvdW4Rv88pRF9XaQb4=.35940454-eb4b-4ced-aa79-23b8ee2023cf@github.com>
Message-ID: <EV3lerHs8TrszLUZNi1KGGMuwlXBjgc2ripbKygBlXk=.fa9e0800-4f79-41cd-a121-b37401f7b8ad@github.com>

On Fri, 23 May 2025 17:52:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Actually It fails with SocketTimeoutException. The test waits target process to connect, but it happens after target app fails with ClassNotFoundException

Okay, thanks.

> I was not able to reproduce 8202971 (400 runs)

Okay, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25366#issuecomment-2905421319

From sspitsyn at openjdk.org  Fri May 23 18:33:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 18:33:53 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
Message-ID: <vUsnONq245WKP8leGzgTKKCrpuR37zkVdCFyQa9pBME=.adbeab99-2699-482b-9afe-a617bcba98eb@github.com>

On Wed, 21 May 2025 20:17:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
> Now I cannot reproduce original test failure, so removing the test from problemlist

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25366#pullrequestreview-2865372902

From sspitsyn at openjdk.org  Fri May 23 18:48:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 18:48:50 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <26dN2RJi1rDeH6PHg7NQ_5VakWqDAivEGRa_FR18pFo=.27ac1a1b-b449-4e09-a37f-f9f780cb7d8f@github.com>

On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25367#pullrequestreview-2865404511

From sspitsyn at openjdk.org  Fri May 23 20:55:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 May 2025 20:55:26 GMT
Subject: RFR: 8357673: remove test
 serviceability/jvmti/vthread/TestPinCaseWithCFLH
Message-ID: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>

The test `test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` was contributed by an external contributor to exercise the `-Djdk.tracePinnedThreads=full` system property when a `javaagent` was involved. The `jdk.tracePinnedThreads` system property is no longer supported by Virtual Threads implementation in mainline. That system property was dropped as part of https://github.com/openjdk/jdk/pull/21565 in JDK 24.
This update removes the test which is not needed anymore.

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

Commit messages:
 - 8357673: remove test serviceability/jvmti/vthread/TestPinCaseWithCFLH

Changes: https://git.openjdk.org/jdk/pull/25424/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25424&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357673
  Stats: 77 lines in 1 file changed: 0 ins; 77 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25424/head:pull/25424

PR: https://git.openjdk.org/jdk/pull/25424

From amenkov at openjdk.org  Fri May 23 21:15:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 May 2025 21:15:52 GMT
Subject: RFR: 8357673: remove test
 serviceability/jvmti/vthread/TestPinCaseWithCFLH
In-Reply-To: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
References: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
Message-ID: <QfeRsXKB5i-oMpP26gu8TN3m4Gs7EzOrOwijU4ox4Lo=.c35e46ad-8b66-4224-93ba-2736bb2d8eb3@github.com>

On Fri, 23 May 2025 20:50:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test `test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` was contributed by an external contributor to exercise the `-Djdk.tracePinnedThreads=full` system property when a `javaagent` was involved. The `jdk.tracePinnedThreads` system property is no longer supported by Virtual Threads implementation in mainline. That system property was dropped as part of https://github.com/openjdk/jdk/pull/21565 in JDK 24.
> This update removes the test which is not needed anymore.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25424#pullrequestreview-2865745538

From jbechberger at openjdk.org  Fri May 23 21:20:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 23 May 2025 21:20:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix compilation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/eaca165d..5e03c9cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=03-04

  Stats: 44 lines in 5 files changed: 18 ins; 5 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From amenkov at openjdk.org  Sat May 24 00:22:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 24 May 2025 00:22:14 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
Message-ID: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>

This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
The update has been split into parts to simplify reviewing.
The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.

Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
  sanity tier1 (this fix only)

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

Commit messages:
 - initial fix

Changes: https://git.openjdk.org/jdk/pull/25425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357650
  Stats: 736 lines in 8 files changed: 733 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From lmesnik at openjdk.org  Sat May 24 02:59:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 24 May 2025 02:59:01 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
Message-ID: <f2qxts06SItGachmXq3zEyyY9Y61iIJnewT6Qd_BFxw=.2e7d9baa-1514-4f25-b7f9-f1846daf01e2@github.com>

On Wed, 21 May 2025 20:17:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
> Now I cannot reproduce original test failure, so removing the test from problemlist

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25366#pullrequestreview-2866037752

From lmesnik at openjdk.org  Sat May 24 02:59:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 24 May 2025 02:59:02 GMT
Subject: RFR: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <oENmA52HeEClkIv0vkK0OeyVpMEP8uZJCD2WivLm3a8=.74a971c9-8464-4e39-9241-570e18f8a93a@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
 <qzzfxNUHsAH8gnO_ctlHmiwUVquMqMzMGI-Zqz4V7so=.99ecd3f9-246e-4bce-9664-4eef20ad3417@github.com>
 <oENmA52HeEClkIv0vkK0OeyVpMEP8uZJCD2WivLm3a8=.74a971c9-8464-4e39-9241-570e18f8a93a@github.com>
Message-ID: <LAvhlMAku1EA8zI2teAVS6xfAgobTRktmkF4Yn1T4DA=.16a73e5c-90d0-406e-86d7-23a0259e5cab@github.com>

On Thu, 22 May 2025 20:38:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/aod/AODRunnerArgParser.java line 109:
>> 
>>> 107:         }
>>> 108: 
>>> 109:         String target = options.getProperty(TARGET_APP_PARAM);
>> 
>> I think it is better to remove -classPath from parameters and 
>> use
>>  ${test.class.path}
>> directly in the test.
>
> The test is run by `nsk.share.aod.AODTestRunner` which runs test app specified by "target" argument.
> Target apps have no system properties like test.class.path

Thanks for explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25366#discussion_r2105680825

From lmesnik at openjdk.org  Sat May 24 03:01:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 24 May 2025 03:01:50 GMT
Subject: RFR: 8357673: remove test
 serviceability/jvmti/vthread/TestPinCaseWithCFLH
In-Reply-To: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
References: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
Message-ID: <lWr3AObTzAp-GHX8Zyc-dhXftGa4wI-Edmsn3v6jOtQ=.1020390b-a6e8-419b-9899-3ba09f125da6@github.com>

On Fri, 23 May 2025 20:50:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test `test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` was contributed by an external contributor to exercise the `-Djdk.tracePinnedThreads=full` system property when a `javaagent` was involved. The `jdk.tracePinnedThreads` system property is no longer supported by Virtual Threads implementation in mainline. That system property was dropped as part of https://github.com/openjdk/jdk/pull/21565 in JDK 24.
> This update removes the test which is not needed anymore.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25424#pullrequestreview-2866038241

From alanb at openjdk.org  Sat May 24 07:40:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 May 2025 07:40:12 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
Message-ID: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>

Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.

This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.

The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.

Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.

Testing: tier1-6

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

Commit messages:
 - Initial commit
 - initial fix

Changes: https://git.openjdk.org/jdk/pull/25429/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25429&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356870
  Stats: 2407 lines in 16 files changed: 1985 ins; 125 del; 297 mod
  Patch: https://git.openjdk.org/jdk/pull/25429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429

PR: https://git.openjdk.org/jdk/pull/25429

From alanb at openjdk.org  Sat May 24 08:10:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 May 2025 08:10:56 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <_6rWUi5bUBoF_LiPCbqhGfKeGswvqz-J2sLozEfjMWU=.f1088973-1005-4cbe-9b6b-a71d91817aea@github.com>

On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

test/hotspot/jtreg/serviceability/dcmd/thread/ClassInitMonitorVThread.java line 71:

> 69:             Thread vthread2 = Thread.ofVirtual().name("Loader2").start(new Loader(loaderReady));
> 70:             loaderReady.await();
> 71:             Thread.sleep(100);

How reliable is this? With a debug build and -Xcomp/other options, then this might not long enough to observe "Loader 2" waiting for the class initializer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25367#discussion_r2105754084

From swen at openjdk.org  Sat May 24 09:39:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 09:39:52 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <GWWc2qqZtdhUizRtbUmyDwST8IWRMG5UJ-seFfOkmGA=.7fd36b7c-81cf-4c08-8ca9-e68fa725d3d2@github.com>

On Sat, 24 May 2025 06:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 56:

> 54:  * thread dump to a file or byte array in plain text or JSON format.
> 55:  */
> 56: public class ThreadDumper {

Suggestion:

public final class ThreadDumper {

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 375:

> 373:      * This class is not intended to be a fully featured JSON writer.
> 374:      */
> 375:     private static class JsonWriter {

Suggestion:

    private static final class JsonWriter {
        private static final class Node {

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 33:

> 31:  * Represents a snapshot of information about a Thread.
> 32:  */
> 33: class ThreadSnapshot {

Suggestion:

final class ThreadSnapshot {

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 182:

> 180:      */
> 181:     private class ThreadLock {
> 182:         private static final OwnedLockType[] lockTypeValues = OwnedLockType.values(); // cache

Suggestion:

        @Stable
        private static final OwnedLockType[] lockTypeValues = OwnedLockType.values();

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 83:

> 81:                 sb.append(System.currentTimeMillis());
> 82:                 String s = sb.toString();
> 83:                 ref.set(s);

Suggestion:

                ref.set(
                        new StringBuffer()
                                .append(System.currentTimeMillis())
                                .toString());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105771285
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105771656
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105770924
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105771148
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105771949

From swen at openjdk.org  Sat May 24 09:43:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 09:43:57 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <XWn1E6bB7ReIitQjBE5OhgZGJ1Zb7tPiNjwSKpwetpc=.f46ab64a-e839-442e-bbbf-368c4fe9b3df@github.com>

On Sat, 24 May 2025 06:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 385:

> 383:             if (name.length() > 0) {
> 384:                 sb.append(",");
> 385:                 sb.append(name);

Suggestion:

                sb.append(",")
                  .append(name);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2105772879

From mgronlun at openjdk.org  Sat May 24 15:22:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 24 May 2025 15:22:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:

> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
> 102:   volatile bool _has_cpu_time_jfr_requests = false;
> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};

Please initialize these fields in the initializer list, like the other fields.

Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2105860988

From jrose at openjdk.org  Sat May 24 17:24:55 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 24 May 2025 17:24:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v5]
In-Reply-To: <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <AGBMDlJXtqLEH2Or6A0BdAFz5fl73StKXpZ8we1LG30=.75fecefa-38db-4537-a9ba-1c8231158b02@github.com>
 <l9L6gdDAfXAZ38vLppXcX0R75Y9bVYSWDjd48-EKLD8=.2cb21710-a6cd-4883-a704-7a784d319a77@github.com>
 <eU9Aclr5QalIHmjEMkDLNJnMGpDnfHNafxm_0EYTmJs=.c96a1692-6d43-46c1-ab51-354a580223a2@github.com>
Message-ID: <_MbHMf8L7i712v1_ROyUoJ1tGJ0ZrSz9xkDAfhwrg6Q=.7c97327a-fea3-4689-b200-c68d9e6dd1a8@github.com>

On Tue, 20 May 2025 23:01:08 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This change adds smaller "fast-forward" table to accelerate random-access queries within a larger stream.
>> 
>> I am not against this change, but I think it should be refactored (either now or later) into a library that can be used with other streamy data.  I'm thinking of debug-info, dependency lists, line number tables, reloc-info, or maybe PC descs as future clients of such a thing.
>> 
>> It could be a query accelerator (index), for any kind of "streamy data" that can get long, and needs occasional random access.
>> 
>> It is good to switch to binary search for big tables, while preserving the speed of linear search for small ones.  A similar technique can also be seen in `PcDescContainer::find_pc_desc_internal`.  Both binary-search algorithms are complicated and difficult to validate.   If we had a suitable library, we could tune it and test it carefully, and use it to simplify field streams, PC descs, and whatever else we need to work with.
>> 
>> BTW, it's sometimes useful to add a front-side cache for such searches.  This is a bookmark of the last query point.  This helps with queries which are correlated; you don't re-search from scratch on every step.  This is the function of `last_pc_desc` in the PC desc query; it can accelerate the binary search.
>> 
>> The fast-forward table here uses an ad hoc var-int scheme which is delicate and possibly buggy.
>> 
>> One way to do without the specialized table is to inject synchronization markers into the streamy data itself.  Note that the null byte is never used to encode UNSIGNED5 data.  Therefore, if you have a stream of UNSIGNED5 tokens, you can add boundaries encoded null bytes.   In the present application, you could perform binary search on the raw stream pointer, with each probe first re-synchronizing to the first null byte, and then decoding with a short sprint of linear access.  The placement of null bytes is a tuning tactic:  More null bytes add footprint but decrease the length of the short sprints.
>> 
>> I'm not asking for any changes at this point because I have not read the PR carefully enough.  And I don't intend to hold up reviews, but I do want us to put refactoring on our roadmap.
>
>> @rose00 While refactoring might be useful, this PR is trying to address a performance regression (in fact by improving the scenario significantly), and I'd prefer that to land in 25
> 
> It will land when it's ready.  It's not quite ready yet.  I'm not asking for reusability, but I am saying that doing a one-off index hack here is exchanging one kind of technical debt (maintenance complexity) for another (performance pothole).  If we hustle to make 25, we need a plan to fix it after 25.
> 
>> rather than to delay just for the sake of better 'reusability'.
> 
> Yes, 'reusability'.  That's how big systems are maintained.
> 
>> And TBH I don't consider binary search algorithm too difficult to validate.
> 
> TBH I do.  I've seen enough OBOEs for one lifetime.  I don't consider even that simple an algorithm to be fully tested unless it is either unit tested (gtest) or stress tested (threshold set small), and preferably both.  Testing it for just a few classes that have many fields is not full coverage.  (Normally for this kind of thing, your hard-coded constant 16 would be made a debug-only globals, and we'd stress-test with it set to 1 or 2.)   Writing a unit test requires enough factorization to write the unit test.  Which also tends towards virtuous reusability.
> 
>> While a simple cache might be useful, I don't have a good example to validate its usefulness. And turning a read-only scenario into mutating scenario can turn out badly for multithreaded code, as in https://bugs.openjdk.org/browse/JDK-8180450 .
> 
> No worries about this one; I'm not asking for such a thing, just noting in passing that it sometimes helps.  Probably not in this case, since you didn't resort the original array, and the usual sequential encounter order is direct, not requiring a cache.  If we were re-engineering PC desc stuff on top of CompressedStream, we'd want such a cache.  Maybe some day.  Some one-element caches have the problem you point out, but if you look at the one-element cache for PC descs you'll see one with no such reported problems.  (IIRC I wrote both.)
> 
>> While you suggest 0 byte as synchronization markers, I've tried to synchronize the stream in #24713 and experiments have shown that while it improves things, it was not sufficient in my case. That's why I've abandoned that approach.
> 
> I looked at that code; thanks.  That wasn't what I meant.  The point of a null resynch byte is to allow *approximate* entry into the main stream.  It is an optional technique that would work like this:
> 
>  ...

> @rose00 I've attempted to extract the binary search in https://github.com/openjdk/jdk/commit/62a40f6b8aafb4a986add0bdac0425dfaf197d62 , but I am not convinced this is better.
> 
> The `SearchTable::lookup` is static now - I am not sure if I could have `class SearchTable: private Array<u1> { ... }` and have that allocated in metaspace...

Thanks for factoring it out.  That helps later adapt the code to other uses, and to unit test now. 

I've been busy with Leyden JEPs the last few days but have also been thinking about your search algo. It might be improbable either now or later. More later on that. 

Thanks for asking about the stress mode. I suggest a debug-only flag named `StressBinarySearch`.  Write a jtreg that exercises it in a debug build set to 1 or 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2906939848

From mgronlun at openjdk.org  Sat May 24 17:50:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 24 May 2025 17:50:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
Message-ID: <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>

On Sat, 24 May 2025 15:19:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:
> 
>> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
>> 102:   volatile bool _has_cpu_time_jfr_requests = false;
>> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};
> 
> Please initialize these fields in the initializer list, like the other fields.
> 
> Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?

I see that JfrCPUTimeTraceQueue::ensure_capacity_for_period() calculates and sets the queue size as a function of the sampling period (in my case its 1 ms).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2105893436

From kustos at gmx.net  Sat May 24 19:26:54 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Sat, 24 May 2025 21:26:54 +0200
Subject: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
Message-ID: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>

Hello

I believe sun.tools.attach.VirtualMachineImpl#checkCatchesAndSendQuitTo 
on Linux leaks file handles after JDK-8327114 [1].

The issue is the line 361 [2]

final var cmdline = Files.lines(procPid.resolve("cmdline")).findFirst();

Because the Stream is not closed the file handle is not closed as well.

Compare this to ProcessHelper#getCommandLine which uses the correct idiom.

try (Stream<String> lines =
     Files.lines(Paths.get("/proc/" + pid + "/cmdline"))) {
     return lines.findFirst().orElse(null);
}

The fix is easy, rewrite the code like so:

final Optional<String> cmdline;
try (var lines = Files.lines(procPid.resolve("cmdline"))) {
     cmdline = lines.findFirst();
}

If somebody opens a JIRA bug I can work on a PR.

  [1] https://bugs.openjdk.org/browse/JDK-8327114
  [2] 
https://github.com/openjdk/jdk/blob/master/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L361
  [3] 
https://github.com/openjdk/jdk/blob/master/src/jdk.jcmd/linux/classes/sun/tools/common/ProcessHelper.java#L117

Regards
Philippe

From jrose at openjdk.org  Sat May 24 20:11:58 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 24 May 2025 20:11:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
Message-ID: <xZjfR4r5VoILZhXZCkcBH-lB2AgOe-Z-2LoThuYcFsQ=.84fd9e63-c60b-4938-b22a-87cf12d95212@github.com>

On Thu, 22 May 2025 08:21:38 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add search table validation

That said, I'm looking at your validation logic to see if a gtest can be deferred until the logic is fully factored. A stress mode test would do it for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2907002921

From jrose at openjdk.org  Sat May 24 20:50:59 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 24 May 2025 20:50:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
Message-ID: <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>

On Thu, 22 May 2025 08:21:38 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add search table validation

Changes requested by jrose (Reviewer).

src/hotspot/share/oops/fieldInfo.cpp line 220:

> 218: }
> 219: 
> 220: #ifdef ASSERT

Thank you for adding this.

Suggest an additional check to validate the binary search:

For each name/sig pair in the field stream, call the lookup function (or its subroutine) and ensure that it steers to the right position in the field stream.

src/hotspot/share/oops/fieldInfo.cpp line 252:

> 250: int FieldInfoReader::search_table_lookup(const Array<u1> *search_table, const Symbol *name, const Symbol *signature, ConstantPool *cp, int java_fields) {
> 251:   UNSIGNED5::Reader<const u1*, int> r2(_r.array());
> 252:   int low = 0, high = java_fields - 1;

This is probably correct, but I recommend a few changes:
A. add an assert `low <= high` at the beginning (defend against surprise `java_fields` number).
B. repeat the assert after each new calculation of high or low.
C. declare high and low and mid as `uint32_t` to prove overflow (UB) impossible without the need to reason about integral range

src/hotspot/share/oops/fieldInfo.cpp line 265:

> 263:     Symbol *mid_name = cp->symbol_at(checked_cast<u2>(r2.next_uint()));
> 264:     Symbol *mid_sig = cp->symbol_at(checked_cast<u2>(r2.next_uint()));
> 265: 

This is the place to use `read_name_and_signature` as requested elsewhere.

src/hotspot/share/oops/fieldInfo.hpp line 273:

> 271:  private:
> 272:   // Don't generate the table for small classes at all.
> 273:   static const int SEARCH_TABLE_THRESHOLD = 16;

One way to create a stress test is to move this to globals.hpp, as a debug-only variable, something like `BinarySearchThreshold` (default 16).  It's OK not to name it more specifically, if (as I believe) this algorithm is destined to be pulled out and used in several places.  Individual uses can scale the number if need be.

src/hotspot/share/oops/fieldInfo.hpp line 276:

> 274: 
> 275:   static inline int search_table_position_width(int stream_length) {
> 276:     assert(stream_length <= (1 << 24), "stream too long");

This assert is OK for here and now.  The binary search widget I have in mind would be 32-bit clean, and therefore would have no surprise limits..

src/hotspot/share/oops/fieldInfo.inline.hpp line 79:

> 77:   fir.read_field_counts(&java_fields_count, &injected_fields_count);
> 78:   return java_fields_count;
> 79: }

Just as these accessors encapsulate the specific order of U5 ints in the header of the stream, I think you should also encapsulate the order of the name and signature, so that your binary-search comparator can read them without assuming their position in the U5 order.  See below.

src/hotspot/share/oops/fieldInfo.inline.hpp line 116:

> 114: }
> 115: 
> 116: inline void FieldInfoReader::read_field_info(FieldInfo& fi) {

I suggest you refactor this guy to use a new API point for the first two fields, `read_name_and_signature`.
Then you can reuse `read_name_and_signature` in the search comparator rather than use dead reckoning.

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2866421214
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105924042
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105924465
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105923610
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105922088
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105922285
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105922865
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2105923077

From liach at openjdk.org  Sun May 25 05:21:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 05:21:00 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>

On Sat, 24 May 2025 06:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

src/hotspot/share/classfile/javaClasses.cpp line 2241:

> 2239: }
> 2240: 
> 2241: class jdk_internal_vm_ThreadLock: AllStatic {

All other class for java classes are declared in javaClasses.hpp. Wonder if runtime would accept a class declared in the cpp file.

src/hotspot/share/classfile/javaClasses.cpp line 5519:

> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
> 5518:   assert(_owner_offset != 0, "Must be initialized");
> 5519:   return obj->obj_field_acquire(_owner_offset);

Is this a preexisting bug? If yes we should have this fixed in a separate patch so it is eligible for backporting, etc.

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 247:

> 245:         var jsonWriter = new JsonWriter(textWriter);
> 246: 
> 247:         jsonWriter.startObject();  // top-level object

Is this anticipated to be used in early bootstrap so we use `startObject` `endObject` instead of using functional code or try-with-resources that create scopes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106087716
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106087007
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106088093

From liach at openjdk.org  Sun May 25 05:21:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 05:21:00 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <GWWc2qqZtdhUizRtbUmyDwST8IWRMG5UJ-seFfOkmGA=.7fd36b7c-81cf-4c08-8ca9-e68fa725d3d2@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <GWWc2qqZtdhUizRtbUmyDwST8IWRMG5UJ-seFfOkmGA=.7fd36b7c-81cf-4c08-8ca9-e68fa725d3d2@github.com>
Message-ID: <1BsLvWj8kQR1qI71PhiPLDXdWrbn-eKKxjSofGw2AUU=.4d80e0af-7201-4f76-ab2f-e81a410dd76c@github.com>

On Sat, 24 May 2025 09:33:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 182:
> 
>> 180:      */
>> 181:     private class ThreadLock {
>> 182:         private static final OwnedLockType[] lockTypeValues = OwnedLockType.values(); // cache
> 
> Suggestion:
> 
>         @Stable
>         private static final OwnedLockType[] lockTypeValues = OwnedLockType.values();

This class can be made final too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106088224

From alanb at openjdk.org  Sun May 25 06:02:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 May 2025 06:02:58 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>
Message-ID: <_FcgfG5KEbEkXE1s0s22JNY_xf4a9X5WbGSYV56v2MY=.59640453-60aa-4d92-b275-0bdf39e6ce18@github.com>

On Sun, 25 May 2025 05:08:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review. The change to src/hotspot and TheadShapshot are in pull/25425.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> src/hotspot/share/classfile/javaClasses.cpp line 5519:
> 
>> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
>> 5518:   assert(_owner_offset != 0, "Must be initialized");
>> 5519:   return obj->obj_field_acquire(_owner_offset);
> 
> Is this a preexisting bug? If yes we should have this fixed in a separate patch so it is eligible for backporting, etc.

This is a dependent PR, there are no changes to src/hotspot in this PR. Maybe I should left this PR in draft until pull/25425 is integrated to avoid any confusion.

In any case, it is changed to use obj_field_acquire because the field is volatile and accessed (asynchronously) from the thread handshake. So different to the access from VM_ThreadDump which is a VM operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106095164

From alanb at openjdk.org  Sun May 25 06:05:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 May 2025 06:05:52 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>
Message-ID: <1FSGo8cojeZcO-NMon9Mv1eG4iobFGVxSjwqRBhEakg=.8fda376a-4850-4bad-aeb9-a604604cacce@github.com>

On Sun, 25 May 2025 05:16:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review. The change to src/hotspot and TheadShapshot are in pull/25425.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 247:
> 
>> 245:         var jsonWriter = new JsonWriter(textWriter);
>> 246: 
>> 247:         jsonWriter.startObject();  // top-level object
> 
> Is this anticipated to be used in early bootstrap so we use `startObject` `endObject` instead of using functional code or try-with-resources that create scopes?

There were several prototypes that use AutoCloseable and other shapes. The intention is to keep as a simple as possible, this is not the focus of the change, and we should be able to eventually replace all this with a better writer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106095592

From alanb at openjdk.org  Sun May 25 06:21:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 May 2025 06:21:05 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review. The change to src/hotspot and TheadShapshot are in pull/25425.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25429/files
  - new: https://git.openjdk.org/jdk/pull/25429/files/52bb3de7..52bb3de7

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429

PR: https://git.openjdk.org/jdk/pull/25429

From alanb at openjdk.org  Sun May 25 06:34:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 May 2025 06:34:50 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <_FcgfG5KEbEkXE1s0s22JNY_xf4a9X5WbGSYV56v2MY=.59640453-60aa-4d92-b275-0bdf39e6ce18@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <9aHFvBN4ISrs7pJKW5kVvqGslPzWuZOV7dUSKuRkm84=.33cd0117-300d-4498-93f8-a1fbf9e6b953@github.com>
 <_FcgfG5KEbEkXE1s0s22JNY_xf4a9X5WbGSYV56v2MY=.59640453-60aa-4d92-b275-0bdf39e6ce18@github.com>
Message-ID: <qj3kCsM-M9dLeJlDxoKqP2IspyLEexuFZEcMRYJFgss=.e0cf0f3f-5104-4670-8dd6-f6e82a1861a4@github.com>

On Sun, 25 May 2025 06:00:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 5519:
>> 
>>> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
>>> 5518:   assert(_owner_offset != 0, "Must be initialized");
>>> 5519:   return obj->obj_field_acquire(_owner_offset);
>> 
>> Is this a preexisting bug? If yes we should have this fixed in a separate patch so it is eligible for backporting, etc.
>
> This is the dependent PR, there are no changes to src/hotspot in this PR. Maybe I should left this PR in draft until pull/25425 is integrated to avoid any confusion.
> 
> In any case, it is changed to use obj_field_acquire because the field is volatile and accessed (asynchronously) from the thread handshake. So different to the access from VM_ThreadDump which is a VM operation.

Okay, I see the issue. The base branch is pull/25425 and the Skara is supposed to retarget once that branch is integrated. It seems to have gone back to master.  I've fixed it now so the Files Changed no longer lists the files in the other PR. Sorry for the confusing. I was initially wondering why there were comments about files that are not in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106100555

From jrose at openjdk.org  Sun May 25 07:21:53 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 25 May 2025 07:21:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
 <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>
Message-ID: <V3FJqoVvaJIb3VzB5-2H5a97UiCgwMSUa-UdPzquGj4=.e259b11b-a3f3-4f68-a33e-6e2033a5e7c5@github.com>

On Sat, 24 May 2025 20:44:06 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add search table validation
>
> src/hotspot/share/oops/fieldInfo.cpp line 252:
> 
>> 250: int FieldInfoReader::search_table_lookup(const Array<u1> *search_table, const Symbol *name, const Symbol *signature, ConstantPool *cp, int java_fields) {
>> 251:   UNSIGNED5::Reader<const u1*, int> r2(_r.array());
>> 252:   int low = 0, high = java_fields - 1;
> 
> This is probably correct, but I recommend a few changes:
> A. add an assert `low <= high` at the beginning (defend against surprise `java_fields` number).
> B. repeat the assert after each new calculation of high or low.
> C. declare high and low and mid as `uint32_t` to prove overflow (UB) impossible without the need to reason about integral range

I looked over the code base for other occurrences of binary search, and I see your code is not an outlier.

The tendency is to use int for high/mid/low, and there are cases where UB would be possible in the absence of extra knowledge about the possible ranges of the ints.  `InstanceKlass::quick_search` is especially scary, until one realizes that method lists are probably on the order of 2^16.  `vmSymbols::find_sid` is the same story; the number of symbols is much less than 2^30..

`GrowableArray::find_sorted` also uses int indexes, but uses a `uint` cast at just the right place when computing mid, to avoid UB, so can handle arrays sized near 2^31.

With those precedents, I'm not going to pick on this code here.  The recommended changes A/B/C are optional.

But I am going to think about what it would take to reduce the number of occurences of binary switch, and build a template that can re-implement at least some of them (probably including yours) with bullet-proof, unit-tested code.

Binary search over 3/4/5-byte packed records is easy, which is what you are doing here.  The use of shortened integers is clever.  I think that can be made a template also, and then used for more than one index, as I've observed before.

One good way to think about these variable-sized packed records is to treat them as physical `uint64_t` values, with high order zero bytes removed.  If you have a word or so of slop area at the bottom of the packed array, you can load 1..8 bytes in a single (misaligned) memory operation, loading garbage into unused bytes, and then using shift or mask to clear the garbage.  That may be faster than asking C++ to do a bunch of branchy logic and byte assembly on every access.  Loading an N-byte word is simply `w=*(uint64_t*)(p+N-8)>>(N*8)`.  Your packed structs have two fields x,y, but they can be reimagined as bitfields `x=w&((1<<xlen)-1)`, `y=w>>xlen`.  This would save half a byte per entry in your tables, on average, since you can often share a byte between the two fields.  And the decode logic would be simpler than the closure-based stuff you have now.

These thoughts are just another observation about the design space you are working in, not a request for changes, although I do think they would simplify your code (and make it more efficient).  This sort of careful design makes the most sense when packaged in a separate class or template,  that can be carefully reviewed and unit-tested in isolation.  If we were to refactor some old searchable data structures onto a more modern footing, I think we would go in such directions.

An interesting property of your jump tables is that they can several kinds of indexes.  You can sort them according to any key in the field-info.  The entries are uniformly index/position (x/y) pairs.  For example, if you sort numerically (either x or y), you get a jump table for random-access into the field-info, given the field id number.  Same data, different sort order, allows acces under different search keys.  Again, this observation is not very actionable now, but it suggeste (to me) that we have a viable mechanism here for several random access problems in the VM.

Kudos to you for suggesting the idea of truncated ints combined with binary search!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2106110163

From stuefe at openjdk.org  Sun May 25 08:15:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 25 May 2025 08:15:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

@parttimenerd 

Drive-by comments:

The ThreadCrashProtection deeply worries me; I have argued against this technique several times in the past, so I will save us the time here. But I don't see it used anywhere in this PR, so is this a remnant from older versions?

The `NoResourceMark` technique does not work as you intend it to work. As a guarantee, this is way too weak.

You want to prevent any use of ResourceMark in a non-reentry way. Just guarding chunk allocation is not sufficient since whether or not we hit those asserts at testing time depends on chunk turnover during testing, and that is highly random, very rare, and very badly fuzzied. A customer could experience a much higher frequency of chunk turnovers if they e.g. enable various combination of log flags. You will never have a good test coverage for that.

To make the `NoResourceMark` safe, you need to guard every single arena allocation path. But I would guess that is way too expensive even for debug builds.

I still think the double-buffering-technique sketched out here https://bugs.openjdk.org/browse/JDK-8349578 is better, and it would be useful outside the context of asynchronous profiling. I'll slot in some days post JDK 25 to explore that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2907682934

From jbechberger at openjdk.org  Sun May 25 08:37:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 08:37:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>
Message-ID: <DmJ8ifkoyWV5C7g4YOi3tuAlXt2eweD5l6qKsC9hsHU=.d2efa7c0-70e5-4538-9423-44be1ed1f085@github.com>

On Sun, 25 May 2025 08:13:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The ThreadCrashProtection deeply worries me; I have argued against this technique several times in the past, so I will save us the time here. But I don't see it used anywhere in this PR, so is this a remnant from older versions?

You're right, I don't know how this ended up in this PR. I'll remove it.

> To make the NoResourceMark safe, you need to guard every single arena allocation path. But I would guess that is way too expensive even for debug builds.

Good to know, then I'll remove the NoResourceMark for now too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2907692503

From mgronlun at openjdk.org  Sun May 25 10:23:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:23:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/jfr.inline.hpp line 35:

> 33: inline bool Jfr::has_sample_request(JavaThread* jt) {
> 34:   assert(jt != nullptr, "invariant");
> 35:   return jt->jfr_thread_local()->has_sample_request() || jt->jfr_thread_local()->has_cpu_time_jfr_requests();

Only need a single dereference of jfr_thread_local() here, not two.

src/hotspot/share/jfr/metadata/metadata.xml line 966:

> 964: 
> 965:   <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
> 966:     description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."

What is the minimal practical sampling period allowed?

src/hotspot/share/jfr/metadata/metadata.xml line 972:

> 970:     <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
> 971:     <Field type="Tickspan" name="samplingPeriod" label="CPU Time Sampling Period"/>
> 972:     <Field type="boolean" name="biased" label="Biased" description="The sample is biased towards the frame at safepoint" />

"The sampled is biased towards the frame at safepoint". What does that mean? Are there three things involved? A sample, a frame and a safepoint? How are they related? See if you can clarify what you intend to communicate here.

src/hotspot/share/jfr/metadata/metadata.xml line 975:

> 973:   </Event>
> 974: 
> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples because of internal throttling"

"Because of internal throttling" seems to blur into the concept of "throttling" unnecessarily. Is there an external and an internal throttling? How are they related? What is the difference?

It is probably better to avoid the term "throttling" altogether here

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 25:

> 23:  */
> 24: 
> 25: #include "gc/shared/barrierSet.hpp"

Is this used / needed?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:

> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 199: 
> 200:   // sample all marked threads out of safepoint

What is mean by "out of safepoint"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 219:

> 217:   void stop_timer();
> 218: 
> 219:   void trigger_out_of_safepoint_sampling();

What is "out of safepoint sampling"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 233:

> 231: }
> 232: 
> 233: JfrCPUTimeThreadSampler::~JfrCPUTimeThreadSampler() {

Can remove.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 561:

> 559:     case _thread_in_native:
> 560:       return true;
> 561:     case _thread_in_vm:

"_thread_in_vm"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 694:

> 692:     while (iter.has_next()) {
> 693:       JavaThread *thread = iter.next();
> 694:       JfrThreadLocal* tl = thread->jfr_thread_local();

A JfrThreadLocal is never null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152036
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152299
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152736
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153242
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153514
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153926
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153992
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154053
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154497
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154997

From mgronlun at openjdk.org  Sun May 25 10:26:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:26:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <Me59DcqMbE3o6__L1QWJbHWaiOQYH4I4l4BQQLhHvDk=.74c8a096-8d23-4661-813d-cec91e11c2f3@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:

> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
> 117:   JfrEventThrottler* const throttler = for_event(event_id);
> 118:   if (throttler == nullptr) {

Should never be possible and so not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106155858

From mgronlun at openjdk.org  Sun May 25 10:30:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:30:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 548:

> 546: #ifdef LINUX
> 547: 
> 548: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {

Can you describe the lock protocol and why a thread must lock its thread-local queue?

Is it because sampling interrupts can interleave after you have started to process a sample as part of a previous interrupt?

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 373:

> 371: #ifdef LINUX
> 372:   void set_cpu_timer(timer_t timer) {
> 373:     _has_cpu_timer = true;

Does not necessarily have to be defined in the .hpp file. Please move to .cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156788
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156997

From jbechberger at openjdk.org  Sun May 25 10:38:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 10:38:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>
Message-ID: <viW35l259PrOKLerBDygCR7rsfyAFfTmpeMHKxpRx1E=.66259c28-6c7f-4225-8053-c62a106efed3@github.com>

On Sun, 25 May 2025 10:27:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 548:
> 
>> 546: #ifdef LINUX
>> 547: 
>> 548: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {
> 
> Can you describe the lock protocol and why a thread must lock its thread-local queue?
> 
> Is it because sampling interrupts can interleave after you have started to process a sample as part of a previous interrupt?

Yes and they can interleave with the safepoint too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106158610

From mgronlun at openjdk.org  Sun May 25 14:45:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:45:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <KVc1WVXPpMKZi4bfw9P8HHkeFF5u9BRrtoVvObNR7nQ=.a05b4bf4-d927-49f4-bb74-141e2e75b620@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 37:

> 35: 
> 36: #include "jfr/recorder/service/jfrOptionSet.hpp"
> 37: #include "jfr/recorder/service/jfrEvent.hpp"

Please check the order of includes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106222301

From mgronlun at openjdk.org  Sun May 25 14:51:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:51:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <lP4Kv7sRdwyT6pWweIDVLqoc2c_JyjpzROfrDGvVDrM=.3d581bb7-d9d8-4c5c-b6cf-04c00f7a9f92@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 28:

> 26: #include "jfr/jfrEvents.hpp"
> 27: #include "jfr/periodic/sampling/jfrThreadSampler.hpp"
> 28: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 355:

> 353: void JfrCPUTimeThreadSampler::sample_out_of_safepoint(JavaThread* thread) {
> 354:   assert(thread->jfr_thread_local() != nullptr, "invariant");
> 355:   JfrThreadLocal* tl = thread->jfr_thread_local();

Perhaps assert tl != nullptr here instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106223669
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106223067

From mgronlun at openjdk.org  Sun May 25 14:56:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:56:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:

> 63:   Thread* raw_thread = Thread::current_or_null_safe();
> 64:   JavaThread* jt;
> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism

Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106225024

From mgronlun at openjdk.org  Sun May 25 15:07:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:07:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <IXJ8OwvQkG8qy4yW_2ZWZ8vmeA-o95Hg4KZkyZ2CVaQ=.8c4bce5c-2ba0-4ccd-858e-e78c71b8826e@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/jfrRecorder.cpp line 33:

> 31: #include "jfr/periodic/jfrOSInterface.hpp"
> 32: #include "jfr/periodic/sampling/jfrThreadSampler.hpp"
> 33: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106227694

From mgronlun at openjdk.org  Sun May 25 15:18:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:18:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:

> 588:   // so samples might be skipped and we have to compute the actual period
> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);

Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 630:

> 628: 
> 629: bool JfrCPUTimeThreadSampler::create_timer_for_thread(JavaThread* thread, timer_t& timerid) {
> 630:   if (thread->osthread() == nullptr || thread->osthread()->thread_id() == 0){

When is this possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106229890
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106230710

From mgronlun at openjdk.org  Sun May 25 15:31:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:31:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:

> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
> 117:   JfrEventThrottler* const throttler = for_event(event_id);
> 118:   if (throttler == nullptr) {

Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106234319

From mgronlun at openjdk.org  Sun May 25 15:35:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:35:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
Message-ID: <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>

On Sun, 25 May 2025 15:29:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:
> 
>> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
>> 117:   JfrEventThrottler* const throttler = for_event(event_id);
>> 118:   if (throttler == nullptr) {
> 
> Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?

Can the settings system be updated so the throttle bit is not set in the native settings struct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106235088

From mgronlun at openjdk.org  Sun May 25 15:42:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:42:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:

> 166:   assert(jt != nullptr, "invariant");
> 167: 
> 168:   biased = false;

Can be moved after the has_last_Java_frame() check.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:

> 360: #ifdef LINUX
> 361:   if (tl->has_cpu_time_jfr_requests()) {
> 362:     JfrTicks now = JfrTicks::now();

You should be able to reuse the already taken now, no?

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375:

> 373:     }
> 374:     queue.clear();
> 375:     tl->release_cpu_time_jfr_queue_lock();

Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106235901
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236251
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236738

From mgronlun at openjdk.org  Sun May 25 15:42:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:42:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
Message-ID: <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>

On Sun, 25 May 2025 15:36:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:
> 
>> 166:   assert(jt != nullptr, "invariant");
>> 167: 
>> 168:   biased = false;
> 
> Can be moved after the has_last_Java_frame() check.

Alternatively its not needed, as it is initialized by the caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236016

From mgronlun at openjdk.org  Sun May 25 15:46:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:46:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <JmMLQxtnXHlk8niCL3qIPCkP3IlbCciH7tbwpQEWGHs=.d196869b-b5a1-477c-8259-3340973e3ab5@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 564:

> 562: }
> 563: 
> 564: void JfrThreadLocal::set_has_cpu_time_jfr_requests(bool has_events) {

"has_events" seems to be an unfortunate naming. "has_requests" I guess?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106237580

From mgronlun at openjdk.org  Sun May 25 16:19:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 16:19:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 365:

> 363:   // idea: this ensures that the frames happened in native
> 364:   // maybe we can wrap this in #ifdef ASSERT if first_index is always 0
> 365:   s4 first_index = queue.size() - 1;

I'm afraid I don't understand this logic at all. If the intent is to share a sid over many requests, why are the individual requests passed to stacktrace.record_inner()?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:

> 371:     }
> 372:   }
> 373:   assert(first_index == 0, "invariant");

How is this possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106244737
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106244850

From mgronlun at openjdk.org  Sun May 25 19:50:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 19:50:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <p0olw0VtNkpCkEhtTxaBgGKtSfINaKBPKmudCl_8Dd0=.6dc3c631-27c4-4809-8626-efabb02f84ae@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:

> 572:   JfrThreadLocal* tl = jt->jfr_thread_local();
> 573:   if (!check_state(jt) ||
> 574:       jt->is_at_poll_safepoint() ||

jt->is_at_poll_safepoint() should be impossible after check_state()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106290963

From mgronlun at openjdk.org  Sun May 25 20:14:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:14:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
Message-ID: <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>

On Sun, 25 May 2025 14:54:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:
> 
>> 63:   Thread* raw_thread = Thread::current_or_null_safe();
>> 64:   JavaThread* jt;
>> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism
> 
> Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?

Also, is raw_thread == nullptr even possible? For the same reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106295956

From mgronlun at openjdk.org  Sun May 25 20:24:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:24:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <Eahg9W0VHfIBpRtgQav7gbPf4P8N8bsQWK7w9mDdjvg=.0478326a-b880-4725-bde5-4b4fa9603104@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 146:

> 144:   s4 lost_samples = Atomic::load_acquire(&_lost_samples);
> 145:   while (Atomic::cmpxchg(&_lost_samples, lost_samples, 0) != lost_samples) {
> 146:     lost_samples = Atomic::load_acquire(&_lost_samples);

You can save and reuse what cmpxchg returns to you.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 169:

> 167: }
> 168: 
> 169: static int64_t compute_sampling_period(double rate);

Why is this fwd declared?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 178:

> 176:   double _rate;
> 177:   bool _autoadapt;
> 178:   volatile int64_t _current_sampling_period_ns = -1;

Please initialize all variables in the constructor's initializer list instead of inline in the header file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106297053
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106297745
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106298076

From mgronlun at openjdk.org  Sun May 25 20:33:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:33:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:

> 376: 
> 377:   void unset_cpu_timer() {
> 378:     _has_cpu_timer = false;

Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106299949

From egahlin at openjdk.org  Sun May 25 20:42:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 25 May 2025 20:42:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java line 269:

> 267:         settingValues.put(EventNames.VirtualThreadSubmitFailed + "#threshold", "0 ns");
> 268:         settingValues.put(EventNames.SecurityProviderService + "#threshold", "0 ns");
> 269:         settingValues.put(EventNames.CPUTimeSampleLoss + "#threshold", "0 ns");

This should not be necessary for JVM events. JDK events are on the list because it was not possible to create instantaneous events in Java (it is now possible).

I see that the CPU Sample event has a duration. What does the duration field indicate when sampling?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106301795

From jbechberger at openjdk.org  Sun May 25 20:51:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 20:51:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
Message-ID: <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>

On Sun, 25 May 2025 20:30:50 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:
> 
>> 376: 
>> 377:   void unset_cpu_timer() {
>> 378:     _has_cpu_timer = false;
> 
> Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?

Do we want to make hard assumptions on timer_t?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106303634

From jbechberger at openjdk.org  Sun May 25 20:51:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 20:51:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
Message-ID: <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>

On Sun, 25 May 2025 20:40:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java line 269:
> 
>> 267:         settingValues.put(EventNames.VirtualThreadSubmitFailed + "#threshold", "0 ns");
>> 268:         settingValues.put(EventNames.SecurityProviderService + "#threshold", "0 ns");
>> 269:         settingValues.put(EventNames.CPUTimeSampleLoss + "#threshold", "0 ns");
> 
> This should not be necessary for JVM events. JDK events are on the list because it was not possible to create instantaneous events in Java (it is now possible).
> 
> I see that the CPU Sample event has a duration. What does the duration field indicate when sampling?

How long the stack walking took. But it's probably irrelevant with the new design.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106303459

From mgronlun at openjdk.org  Sun May 25 21:11:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:11:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
Message-ID: <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>

On Sun, 25 May 2025 20:49:37 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:
>> 
>>> 376: 
>>> 377:   void unset_cpu_timer() {
>>> 378:     _has_cpu_timer = false;
>> 
>> Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?
>
> Do we want to make hard assumptions on timer_t?

You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106307666

From mgronlun at openjdk.org  Sun May 25 21:28:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:28:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:

> 599: 
> 600:   if (jt->thread_state() == _thread_in_native &&
> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {

Is this testing what you intend? The precedence order is [*, / ], from left to right associativity

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106311361

From mgronlun at openjdk.org  Sun May 25 21:32:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:32:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <y2X5AHjzs1u3xGHuaY0LA4sYrzCJKE4QeVS_JRRs5_M=.803399c0-b155-4cb1-b531-d584022d43e6@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 374:

> 372:       JfrCPUTimeThreadSampling::send_lost_event( now, JfrThreadLocal::thread_id(jt), queue.get_and_reset_lost_samples());
> 373:     }
> 374:     queue.clear();

queue.clear() is the same operation as queue.set_size(0) on line 368.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106312208

From egahlin at openjdk.org  Sun May 25 21:37:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 25 May 2025 21:37:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
 <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
Message-ID: <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>

On Sun, 25 May 2025 20:48:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> How long the stack walking took. But it's probably irrelevant with the new design.

It will probably confuse user more than help them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106313187

From mgronlun at openjdk.org  Sun May 25 21:40:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:40:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <1EjAxFqZsL3bcgfK1d7eJWqpejhNG5MsInZmbJb1WFA=.e3c23329-a5a8-4fce-9296-22ffff247933@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 401:

> 399: 
> 400:   JfrCPUTimeTraceQueue& cpu_time_jfr_queue();
> 401:   void disable_cpu_time_jfr_queue();

Seems a bit strange that you can "disable" a queue. When is it enabled? Since the underlying implementation delegates to ensure_capacity for size == 0, and deallocates, perhaps a more appropriate name is "deallocate_cpu_time_jfr_queue()"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106313484

From jbechberger at openjdk.org  Mon May 26 06:31:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
 <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>
Message-ID: <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@github.com>

On Sun, 25 May 2025 20:12:09 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:
>> 
>>> 63:   Thread* raw_thread = Thread::current_or_null_safe();
>>> 64:   JavaThread* jt;
>>> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism
>> 
>> Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?
>
> Also, is raw_thread == nullptr even possible? For the same reasons.

`!raw_thread->is_Java_thread()` I found it during testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106643535

From jbechberger at openjdk.org  Mon May 26 06:31:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
Message-ID: <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>

On Sun, 25 May 2025 16:17:12 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:
> 
>> 371:     }
>> 372:   }
>> 373:   assert(first_index == 0, "invariant");
> 
> How is this possible?

Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:
> 
>> 588:   // so samples might be skipped and we have to compute the actual period
>> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
>> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);
> 
> Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.

Could you give me a hand with the conversion?

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375:
> 
>> 373:     }
>> 374:     queue.clear();
>> 375:     tl->release_cpu_time_jfr_queue_lock();
> 
> Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock?

These are not really different locks, as the lock has four different states. So it just changes the lock state from DEQUEUE to UNLOCKED.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106637673
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106642499
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106639331

From jbechberger at openjdk.org  Mon May 26 06:31:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
Message-ID: <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>

On Sun, 25 May 2025 21:09:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Do we want to make hard assumptions on timer_t?
>
> You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.

Wouldn't I need to store it somewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106634421

From jbechberger at openjdk.org  Mon May 26 06:34:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:34:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>

On Sun, 25 May 2025 10:16:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
> 
>> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
>> 199: 
>> 200:   // sample all marked threads out of safepoint
> 
> What is meant by "out of safepoint"?

Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106647626

From jbechberger at openjdk.org  Mon May 26 06:38:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:38:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <qXLIwSFFMQ347gAA1-HPvS-hr7Qu9MPkfkw66Gwcjjs=.03777399-1f98-4435-8075-710872f2486d@github.com>

On Sun, 25 May 2025 10:08:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/metadata/metadata.xml line 966:
> 
>> 964: 
>> 965:   <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
>> 966:     description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."
> 
> What is the minimal practical sampling period allowed?

Depends on your system: It is configured via `CONFIG_HZ` at build time. This value is usually between 250 and 1000 Hz. We could proactively lower-bound the interval to 1ms or just state it in the description.

> src/hotspot/share/jfr/metadata/metadata.xml line 972:
> 
>> 970:     <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
>> 971:     <Field type="Tickspan" name="samplingPeriod" label="CPU Time Sampling Period"/>
>> 972:     <Field type="boolean" name="biased" label="Biased" description="The sample is biased towards the frame at safepoint" />
> 
> "The sample is biased towards the frame at safepoint". What does that mean? Are there three things involved? A sample, a frame and a safepoint? How are they related? See if you can clarify what you intend to communicate here.

Maybe better: "The sample is safepoint-biased"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106652540
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106653359

From jbechberger at openjdk.org  Mon May 26 08:16:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:16:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
 <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>
Message-ID: <--htE9vU4m2HJ_ZrauUWBuHcQA-w-SCvRLisaYA_9KI=.588586a8-5d20-4abe-90d4-87fc0a3304a9@github.com>

On Sat, 24 May 2025 17:48:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:
>> 
>>> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
>>> 102:   volatile bool _has_cpu_time_jfr_requests = false;
>>> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};
>> 
>> Please initialize these fields in the initializer list, like the other fields.
>> 
>> Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?
>
> I see that JfrCPUTimeTraceQueue::ensure_capacity_for_period() calculates and sets the queue size as a function of the sampling period (in my case its 1 ms).

I reduced the base capacity to 500, but with far smaller values we risk many more lossed events. We should probably tune this value at the end.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106782239

From mgronlun at openjdk.org  Mon May 26 08:16:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:16:10 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
Message-ID: <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>

On Mon, 26 May 2025 06:23:08 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.
>
> Wouldn't I need to store it somewhere?

Of course. A pointer is less space compared to an inlined struct AND a bool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106793364

From jbechberger at openjdk.org  Mon May 26 08:24:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:24:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <UpJCmbSDSRS2F3kVksmroS6ZKHnFHcLOcCntPYEfiF8=.26c444b7-f433-4d2e-a5fe-8afd5f11435e@github.com>

On Sun, 25 May 2025 10:14:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 25:
> 
>> 23:  */
>> 24: 
>> 25: #include "gc/shared/barrierSet.hpp"
> 
> Is this used / needed?

Good catch

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 219:
> 
>> 217:   void stop_timer();
>> 218: 
>> 219:   void trigger_out_of_safepoint_sampling();
> 
> What is "out of safepoint sampling"?

See above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106811373
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106805944

From mgronlun at openjdk.org  Mon May 26 08:24:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:24:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
Message-ID: <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>

On Mon, 26 May 2025 06:32:03 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
>> 
>>> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
>>> 199: 
>>> 200:   // sample all marked threads out of safepoint
>> 
>> What is meant by "out of safepoint"?
>
> Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.

A thread in native is still stackwalked at a safe location, a safepoint code position.

It's guaranteed by the last java frame (ljf).

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:
>> 
>>> 371:     }
>>> 372:   }
>>> 373:   assert(first_index == 0, "invariant");
>> 
>> How is this possible?
>
> Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.

There is no safepoint when a thread goes from Java to native.

It's done on the way back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106808431
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106814829

From jbechberger at openjdk.org  Mon May 26 08:24:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:24:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
Message-ID: <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>

On Mon, 26 May 2025 08:08:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Wouldn't I need to store it somewhere?
>
> Of course. A pointer is less space compared to an inlined struct AND a bool.

But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106810141

From ihse at openjdk.org  Mon May 26 08:25:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:25:07 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <-HdnkBjrOxo3jUA8jSYhmElKM55oIcSRYYgu70KPR8M=.24dfddf4-6890-4a61-9cef-85f1a2c1238a@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@JoeWang-Java @naotoj Can you help review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908936863

From ihse at openjdk.org  Mon May 26 08:27:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:27:45 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@justin-curtis-lu Are these files handled by the translation team?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908942083

From jbechberger at openjdk.org  Mon May 26 08:33:12 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:33:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
Message-ID: <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>

On Mon, 26 May 2025 08:18:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.
>
> A thread in native is still stackwalked at a safe location, a safepoint code position.
> 
> It's guaranteed by the last java frame (ljf).

Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.

>> Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.
>
> There is no safepoint when a thread goes from Java to native.
> 
> It's done on the way back.

Ok, then I need my check. The check ensures that I only walk stacks that have the same top Java frame as the current frame (which is by design related to a stack trace in native). I don't want to walk non-native thread state stack traces here.

This is implemented to ensure that we also sample threads while they are in a long native period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106829651
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106825442

From mgronlun at openjdk.org  Mon May 26 08:33:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:33:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
 <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
Message-ID: <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>

On Mon, 26 May 2025 08:19:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Of course. A pointer is less space compared to an inlined struct AND a bool.
>
> But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?

You store the pointer in JfrThreadLocal, instead of the inlined timer_t struct.

One benefit is that you can fwd declare the type and need not include its header.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106825673

From mgronlun at openjdk.org  Mon May 26 08:33:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:33:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
 <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
 <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>
Message-ID: <wvfmtLUHoCUutf8l99iIy2F2Or95uZgWrBm6M6SHVT0=.78748013-9b21-4dcf-a50b-2c6b5e9cc911@github.com>

On Mon, 26 May 2025 08:27:51 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?
>
> You store the pointer in JfrThreadLocal, instead of the inlined timer_t struct.
> 
> One benefit is that you can fwd declare the type and need not include its header.

C heap allocated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106829884

From mgronlun at openjdk.org  Mon May 26 09:33:30 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 09:33:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
Message-ID: <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>

On Mon, 26 May 2025 08:30:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> A thread in native is still stackwalked at a safe location, a safepoint code position.
>> 
>> It's guaranteed by the last java frame (ljf).
>
> Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.

That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.

"Sampling" is the process of saving and enqueing a JfrSampleRequest.

"Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?

"out of safepoint" does not make any sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106887879

From jbechberger at openjdk.org  Mon May 26 09:33:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v6]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Vq37TpakBo68qWj62_9yzPKvHbNL5TuX1IDnyR-C7Ks=.16f00cf5-55a0-42bf-bca8-fdf1f33fc159@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with six additional commits since the last revision:

 - Improve names
 - Refactor
   
   Rename out_of_safepoint to thread_in_native and more
 - Refactoring
 - Revert ThreadCrashProtection change
 - Remove NoResourceMark
 - Reduce base queue capacity to 500 from 1000

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/5e03c9cf..403444f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=04-05

  Stats: 200 lines in 14 files changed: 41 ins; 92 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Mon May 26 09:33:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 09:33:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
 <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
Message-ID: <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>

On Mon, 26 May 2025 09:02:39 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.
>
> That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.
> 
> "Sampling" is the process of saving and enqueing a JfrSampleRequest.
> 
> "Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?
> 
> "out of safepoint" does not make any sense.

Walking from an ljf is walking at a safepoint by design. Its just that in this case, you delegate to another thread to do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106894866

From jbechberger at openjdk.org  Mon May 26 09:33:31 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
 <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
 <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>
Message-ID: <FBWMl4ishFqhM9pPtT4f-fEXRYGNYsHIzGlAe2QAB48=.b87042d8-c438-46bd-9881-4283a3e85992@github.com>

On Mon, 26 May 2025 09:07:12 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.
>> 
>> "Sampling" is the process of saving and enqueing a JfrSampleRequest.
>> 
>> "Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?
>> 
>> "out of safepoint" does not make any sense.
>
> Walking from an ljf is walking at a safepoint by design. Its just that in this case, you delegate to another thread to do it.

I improved the names (changed it to `thread_in_native_stackwalking`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106909231

From jbechberger at openjdk.org  Mon May 26 09:33:36 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>
Message-ID: <C0xRqn7czRVsHqhUPRn3T3Nmoox2Pts8t8XJqJWfhlc=.f8f59d3e-2153-49fa-8a99-8b9dfd3720c1@github.com>

On Sun, 25 May 2025 15:16:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 630:
> 
>> 628: 
>> 629: bool JfrCPUTimeThreadSampler::create_timer_for_thread(JavaThread* thread, timer_t& timerid) {
>> 630:   if (thread->osthread() == nullptr || thread->osthread()->thread_id() == 0){
> 
> When is this possible?

I removed it.

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
> 
>> 360: #ifdef LINUX
>> 361:   if (tl->has_cpu_time_jfr_requests()) {
>> 362:     JfrTicks now = JfrTicks::now();
> 
> You should be able to reuse the already taken now, no?

Good catch.

> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 564:
> 
>> 562: }
>> 563: 
>> 564: void JfrThreadLocal::set_has_cpu_time_jfr_requests(bool has_events) {
> 
> "has_events" seems to be an unfortunate naming. "has_requests" I guess?

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106858516
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106862855
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106864886

From jbechberger at openjdk.org  Mon May 26 09:33:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
Message-ID: <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>

On Mon, 26 May 2025 06:28:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:
>> 
>>> 588:   // so samples might be skipped and we have to compute the actual period
>>> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
>>> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);
>> 
>> Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.
>
> Could you give me a hand with the conversion?

My code is the inversion of


template <typename TimeSource, const int unit>
inline double conversion(typename TimeSource::Type& value) {
  return (double)value * ((double)unit / (double)TimeSource::frequency());
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106855512

From jbechberger at openjdk.org  Mon May 26 09:33:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
 <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>
Message-ID: <lsRdrCALyrsnVkVLuNOXrsL4HnMXk6q_EDQ5iZZwo7U=.4cbbdc3b-a2dd-4bee-a8c5-d0cb8ea7d336@github.com>

On Sun, 25 May 2025 15:37:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:
>> 
>>> 166:   assert(jt != nullptr, "invariant");
>>> 167: 
>>> 168:   biased = false;
>> 
>> Can be moved after the has_last_Java_frame() check.
>
> Alternatively its not needed, as it is initialized by the caller.

I removed the assignment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106860624

From jbechberger at openjdk.org  Mon May 26 09:40:38 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:40:38 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
 <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
 <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>
Message-ID: <VJahctNr9Ri4nLXlp4BC6G8k0GelGejgl7cwAOYzb-0=.7ede5f91-b4a6-4bf6-9f12-a4d15e966836@github.com>

On Sun, 25 May 2025 21:35:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> How long the stack walking took. But it's probably irrelevant with the new design.
>
>> How long the stack walking took. But it's probably irrelevant with the new design.
> 
> It will probably confuse user more than help them.

I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106946609

From jbechberger at openjdk.org  Mon May 26 09:48:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:48:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
Message-ID: <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>

On Sun, 25 May 2025 21:25:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:
> 
>> 599: 
>> 600:   if (jt->thread_state() == _thread_in_native &&
>> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {
> 
> Is this testing what you intend? The precedence order is [*, / ], from left to right associativity

I can't follow. This is testing whether the queue is more than two thirds full.

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 374:
> 
>> 372:       JfrCPUTimeThreadSampling::send_lost_event( now, JfrThreadLocal::thread_id(jt), queue.get_and_reset_lost_samples());
>> 373:     }
>> 374:     queue.clear();
> 
> queue.clear() is the same operation as queue.set_size(0) on line 368.

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106957537
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106960969

From jbechberger at openjdk.org  Mon May 26 10:10:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:10:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v7]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HFfSy6DViA6MNcOMhC87efQ9Qy168ruh0yTTu1gePwQ=.c8c1143a-441c-46b6-bbd5-f473bf7135f8@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Improve queue walking in native
 - Rename and remove end_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/403444f8..e3addfe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=05-06

  Stats: 68 lines in 7 files changed: 24 ins; 18 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 10:10:20 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:10:20 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
Message-ID: <3jd1OlChIF9OqHGiowJwsi_oCDx3kI1vwm2Rqx-PIZ0=.190480fc-bafb-4b67-a5da-6dd955737824@github.com>

On Sun, 25 May 2025 16:16:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 365:
> 
>> 363:   // idea: this ensures that the frames happened in native
>> 364:   // maybe we can wrap this in #ifdef ASSERT if first_index is always 0
>> 365:   s4 first_index = queue.size() - 1;
> 
> I'm afraid I don't understand this logic at all. If the intent is to share a sid over many requests, why are the individual requests passed to stacktrace.record_inner()?

I rewrote the code and store the first native request index directly in the queue. Therefore we only need to walk the queue once.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106997891

From mgronlun at openjdk.org  Mon May 26 10:27:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 10:27:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
 <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
Message-ID: <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>

On Mon, 26 May 2025 09:44:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:
>> 
>>> 599: 
>>> 600:   if (jt->thread_state() == _thread_in_native &&
>>> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {
>> 
>> Is this testing what you intend? The precedence order is [*, / ], from left to right associativity
>
> I can't follow. This is testing whether the queue is more than two thirds full.

I'm sorry, I read this wrong. In this case, it does not matter: (capacity * 2) / 3 == capacity * (2/3)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107027793

From jbechberger at openjdk.org  Mon May 26 10:31:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:31:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
 <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
 <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>
Message-ID: <7u_T3IBu6hSXVH9Ebobv_Rdv8vOVaAPd_nxtyAHBq_o=.74c6955d-61c8-4c45-83df-5c402543bb61@github.com>

On Mon, 26 May 2025 10:25:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I can't follow. This is testing whether the queue is more than two thirds full.
>
> I'm sorry, I read this wrong. In this case, it does not matter: (capacity * 2) / 3 == capacity * (2/3)

I ignored the small underflow, so `size() * 3 > capacity() * 2` is more accurate, but far less readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107034280

From jbechberger at openjdk.org  Mon May 26 11:24:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 11:24:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v8]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <SiitD-ot9bi4Mrf8CsrKlAhd-8EnYZau0w9nJmC3WBU=.c14b6535-7d67-4403-a530-d091f664dc3c@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Move timer_t onto the heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e3addfe0..145fe20d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=06-07

  Stats: 40 lines in 3 files changed: 13 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 12:03:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:03:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v9]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Q5EObyE83819wq8UXD0B2PO3dNgE__-Axuq80n_7ZjU=.3332a829-4fa6-4ffa-ab3e-87739bfdec4a@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve throttle hot path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/145fe20d..d071acc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 12:03:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:03:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
 <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>
Message-ID: <pe7fzLwGPoXhMp0aJzRv0theyZyGJgJBzHvX9mkuFxs=.46149ce4-dcc1-40f7-bdca-c7be900516f3@github.com>

On Sun, 25 May 2025 15:33:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:
>> 
>>> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
>>> 117:   JfrEventThrottler* const throttler = for_event(event_id);
>>> 118:   if (throttler == nullptr) {
>> 
>> Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?
>
> Can the settings system be updated so the throttle bit is not set in the native settings struct?

I just created a throttler which is always disabled. This uses a bit more memory, but doesn't need any special handling for CPUTimeSample events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107188550

From jbechberger at openjdk.org  Mon May 26 12:29:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:29:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Don't mention throttling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d071acc9..cfbc25a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Mon May 26 14:06:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 14:06:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
Message-ID: <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>

On Mon, 26 May 2025 08:44:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Could you give me a hand with the conversion?
>
> My code is the inversion of
> 
> 
> template <typename TimeSource, const int unit>
> inline double conversion(typename TimeSource::Type& value) {
>   return (double)value * ((double)unit / (double)TimeSource::frequency());
> }

(value * (unit / frequency)) != (value / unit * frequency)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107424093

From egahlin at openjdk.org  Mon May 26 14:13:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 14:13:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
Message-ID: <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>

On Mon, 26 May 2025 12:29:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't mention throttling

Having four views for the CPU-Time events seems excessive, especially since it's an experimental event. Is it possible to reduce this to two views: the hot-methods table and a "form" view where all the aggregates are displayed?

Labels should use headline-style capitalization, capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs. Do not include ending punctuation.
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jfr/jdk/jfr/Label.html

Also, put (Experimental) at the end of the title.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909886888

From jbechberger at openjdk.org  Mon May 26 14:13:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:13:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
Message-ID: <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>

On Mon, 26 May 2025 14:04:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> My code is the inversion of
>> 
>> 
>> template <typename TimeSource, const int unit>
>> inline double conversion(typename TimeSource::Type& value) {
>>   return (double)value * ((double)unit / (double)TimeSource::frequency());
>> }
>
> (value * (unit / frequency)) != (value / unit * frequency)

The mentioned conversion is from ticks to time unit:

nanos = ticks * 1_000_000_000 / frequency

therefore

nanos / 1_000_000_000 * frequency = ticks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107432668

From jbechberger at openjdk.org  Mon May 26 14:16:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:16:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
Message-ID: <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>

On Mon, 26 May 2025 14:11:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Also, put (Experimental) at the end of the title.

This is added automatically. If I add "(Experimental)" to the title, then I get "X (Experimental) (Experimental)"

> "form" view where all the aggregates are displayed?

I'm unsure how to implement this using the SQL version that is used for the views

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909896289

From jbechberger at openjdk.org  Mon May 26 14:25:45 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:25:45 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v11]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <hJefdgnpEdzy9PX2g2v17uvOxsE8Sa8214EVnYthA_w=.63783f40-3033-461e-be30-0354fbcb4453@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix default.jfc and profile.jfc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/cfbc25a0..8cfedaee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=09-10

  Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From egahlin at openjdk.org  Mon May 26 14:25:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 14:25:46 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
Message-ID: <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>

On Mon, 26 May 2025 14:14:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is added automatically. If I add "(Experimental)" to the title, then I get "X (Experimental) (Experimental)"

Sweet.

> I'm unsure how to implement this using the SQL version that is used for the views

I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909912821

From mgronlun at openjdk.org  Mon May 26 14:46:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 14:46:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
Message-ID: <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>

On Mon, 26 May 2025 14:09:35 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> (value * (unit / frequency)) != (value / unit * frequency)
>
> The mentioned conversion is from ticks to time unit:
> 
> nanos = ticks * 1_000_000_000 / frequency
> 
> therefore
> 
> nanos / 1_000_000_000 * frequency = ticks

Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.

Does it look right in the jfr parser alt JMC?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107489332

From jbechberger at openjdk.org  Mon May 26 14:57:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:57:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v12]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <ehSHEuuUy_evOHMDtT_xHUpIBUWkL3EYmA_tTmkzusQ=.6a6929d6-3bbc-4bcd-bb4b-ce51a6cbffbc@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix MacOS build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8cfedaee..d89ae716

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=10-11

  Stats: 9 lines in 2 files changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 15:07:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:07:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
Message-ID: <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>

On Mon, 26 May 2025 14:44:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The mentioned conversion is from ticks to time unit:
>> 
>> nanos = ticks * 1_000_000_000 / frequency
>> 
>> therefore
>> 
>> nanos / 1_000_000_000 * frequency = ticks
>
> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
> 
> Does it look right in the jfr parser alt JMC?

It looks good in the jfr tool:


16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false


But I can't find the event at all in JMC

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107525890

From mgronlun at openjdk.org  Mon May 26 15:12:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 15:12:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
Message-ID: <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>

On Mon, 26 May 2025 15:05:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
>> 
>> Does it look right in the jfr parser alt JMC?
>
> It looks good in the jfr tool:
> 
> 
> 16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
> 16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false
> 
> 
> But I can't find the event at all in JMC

You need to expand the Event Browser section and locate your event, Johannes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107533366

From jbechberger at openjdk.org  Mon May 26 15:15:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:15:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
Message-ID: <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIolnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>

On Mon, 26 May 2025 15:09:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It looks good in the jfr tool:
>> 
>> 
>> 16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
>> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
>> 16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false
>> 
>> 
>> But I can't find the event at all in JMC
>
> You need to expand the Event Browser section and locate your event, Johannes.

![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107545776

From jbechberger at openjdk.org  Mon May 26 15:35:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:35:44 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v13]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <coxWff1b1pcDwUsPoDDML8tZhd-BQQBpDSiu42lr064=.48d2588f-32ca-4660-9987-45db30782e67@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve one warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d89ae716..ae0747d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 15:35:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:35:44 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIolnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
 <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIo
 lnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
Message-ID: <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>

On Mon, 26 May 2025 15:12:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> You need to expand the Event Browser section and locate your event, Johannes.
>
> ![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)

> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.

I don't. I represent it as a Tickspan, as I substract two TimeInstants:


  TimeInterval<Rep, TimeSource> operator-(const TimeInstant<Rep, TimeSource>& start) const {
    return TimeInterval<Rep, TimeSource>(*this, start);
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107571501

From jbechberger at openjdk.org  Mon May 26 15:42:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:42:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
 <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIo
 lnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
 <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>
Message-ID: <jMGsShGuugUFc9CksRSD2FAz_0ue-g2-asHqO0ByixA=.3cdf480c-1281-4d59-a532-b4948c323a2c@github.com>

On Mon, 26 May 2025 15:31:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> ![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)
>
>> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
> 
> I don't. I represent it as a Tickspan, as I substract two TimeInstants:
> 
> 
>   TimeInterval<Rep, TimeSource> operator-(const TimeInstant<Rep, TimeSource>& start) const {
>     return TimeInterval<Rep, TimeSource>(*this, start);
>   }

Regarding JMC: I had to enable the experimental events in the preferences. Now it shows:

![image](https://github.com/user-attachments/assets/d31efde1-6075-4be6-b61f-91e5786637de)

So all is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107580724

From egahlin at openjdk.org  Mon May 26 15:45:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 15:45:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
Message-ID: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>

On Mon, 26 May 2025 14:20:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.

I have a Mac, so I could not try it with an actual recording, but something like this:

[application.cpu-time-statistics]
label = "CPU Time Samples Statistics"
form = "COLUMN 'Successful Samples', 'Failed Samples', 'Total Samples', 'Lost Samples'
        SELECT COUNT(T.failed), COUNT(F.failed), Count(A.failed), SUM(L.lostSamples)
        FROM 
          CPUTimeSample AS T,
          CPUTimeSample AS F,
          CPUTimeSample AS A,
          CPUTimeSampleLoss AS L
        WHERE
          T.failed = 'true' AND
          F.failed = 'false'"


 I removed biased, because I wonder If we should have such a field? There can be many types of biases, and the implementation may change in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2910137003

From jbechberger at openjdk.org  Mon May 26 15:48:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:48:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
Message-ID: <H4taesXEidY4TfbhEwOzeokgu9vA3yJ3Qwkj5u0yQPU=.5407cdc1-ec19-4d66-8b7a-7d8a6ea657ed@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I removed biased, because I wonder If we should have such a field? There can be many types of biases, and the implementation may change in the future.

This signifies that the sample has a known bias. It is important for the user to distinguish between biased and unbiased samples.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2910142902

From aturbanov at openjdk.org  Mon May 26 16:08:52 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 May 2025 16:08:52 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>
Message-ID: <5eja36GwtLPqwerJOWLntBLTniWqF3v1ap-ODCxukRg=.03773d4a-ed4c-4e0c-92c4-1c2e78956207@github.com>

On Sun, 25 May 2025 06:21:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 186:

> 184:         Thread.State state = snapshot.threadState();
> 185:         writer.println("#" + thread.threadId() + " \"" + snapshot.threadName()
> 186:                 +  "\" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);

Suggestion:

                + "" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2107609822

From shade at openjdk.org  Mon May 26 17:30:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 May 2025 17:30:05 GMT
Subject: RFR: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
Message-ID: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>

[JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25458/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357800
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25458/head:pull/25458

PR: https://git.openjdk.org/jdk/pull/25458

From jbechberger at openjdk.org  Mon May 26 18:36:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 18:36:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v14]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <zLfDb2lWdLmGbdR2Xuyf0JVf16NFKpMsOahsI0qF24E=.2caecb86-0386-4d1b-b92b-75dfd1a489d8@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix other platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ae0747d4..f64b1dcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=12-13

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

PR: https://git.openjdk.org/jdk/pull/25302

From liach at openjdk.org  Mon May 26 18:48:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 18:48:52 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <fyfXoqa91NWEG7o9O-qDvtn3r7AvYmaDQaq0xq9yNyI=.daf838b9-8006-4c7b-b11b-59885cab6748@github.com>

On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

src/hotspot/share/classfile/javaClasses.cpp line 2241:

> 2239: }
> 2240: 
> 2241: class jdk_internal_vm_ThreadLock: AllStatic {

A bit unusual to declare class for java class in the cpp file - all others are declared in the hpp file.

src/hotspot/share/classfile/javaClasses.cpp line 5519:

> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
> 5518:   assert(_owner_offset != 0, "Must be initialized");
> 5519:   return obj->obj_field_acquire(_owner_offset);

We might split this into a separate patch if this affects existing usages in threadService.cpp.

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 33:

> 31:  * Represents a snapshot of information about a Thread.
> 32:  */
> 33: class ThreadSnapshot {

All class declarations here should be made final (except enum and record which are already implicitly final)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2106198342
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2106198093
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2107742069

From alanb at openjdk.org  Mon May 26 19:02:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:02:51 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <fyfXoqa91NWEG7o9O-qDvtn3r7AvYmaDQaq0xq9yNyI=.daf838b9-8006-4c7b-b11b-59885cab6748@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <fyfXoqa91NWEG7o9O-qDvtn3r7AvYmaDQaq0xq9yNyI=.daf838b9-8006-4c7b-b11b-59885cab6748@github.com>
Message-ID: <Mz8Prkyk0GS68G5CrylupwBEAmxYH1DfRlOukxh9OnQ=.f15df267-4951-46b9-9582-784994ad75ab@github.com>

On Sun, 25 May 2025 13:11:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> src/hotspot/share/classfile/javaClasses.cpp line 5519:
> 
>> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
>> 5518:   assert(_owner_offset != 0, "Must be initialized");
>> 5519:   return obj->obj_field_acquire(_owner_offset);
> 
> We might split this into a separate patch if this affects existing usages in threadService.cpp.

The pre-existing usage is from a VM operation so I don't think there is an existing issue. The new usage is in handshake operation and this field is on the ownable synchronizer rather than the thread so need to change it.

> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 33:
> 
>> 31:  * Represents a snapshot of information about a Thread.
>> 32:  */
>> 33: class ThreadSnapshot {
> 
> All class declarations here should be made final (except enum and record which are already implicitly final)

This is a JDK internal class, it doesn't really need to be final but it should have a private constructor to at least avoid something in this internal package from creating one directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2107753356
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2107754207

From alanb at openjdk.org  Mon May 26 19:08:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:08:50 GMT
Subject: RFR: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
In-Reply-To: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
References: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
Message-ID: <-nPvEWQjtALFweg25GJoX1DLnXK63zn5rGn5NXDWz6Y=.582b35be-c65f-4882-8f7d-bbd2495f6b34@github.com>

On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/jvmti`

Looks right

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

PR Review: https://git.openjdk.org/jdk/pull/25458#pullrequestreview-2869038288

From alanb at openjdk.org  Mon May 26 19:29:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:29:50 GMT
Subject: RFR: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
In-Reply-To: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
References: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
Message-ID: <JjICRJKusf96WcSntfOolFr1gP6IiElbM9HirGHKE3I=.e7fd676b-1634-46e6-ab60-d79128505008@github.com>

On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/jvmti`

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25458#pullrequestreview-2869071215

From jbechberger at openjdk.org  Mon May 26 19:32:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 19:32:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v15]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <5ph_cQumwYk_z6UyCLNm4WeqAieMPisNb14hsbYoWQQ=.9ae3bb91-4d12-4d85-ab9c-f71ba84b8705@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix other platforms
 - Improve one warning
 - Fix MacOS build
 - Fix default.jfc and profile.jfc
 - Don't mention throttling
 - Improve throttle hot path
 - Move timer_t onto the heap
 - Improve queue walking in native
 - Rename and remove end_time
 - ... and 73 more: https://git.openjdk.org/jdk/compare/bbceab07...57da22e0

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=14
  Stats: 2353 lines in 45 files changed: 2207 ins; 129 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 19:38:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 19:38:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/57da22e0..d49b0084

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=14-15

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

PR: https://git.openjdk.org/jdk/pull/25302

From duke at openjdk.org  Mon May 26 20:01:02 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 26 May 2025 20:01:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
Message-ID: <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>

On Mon, 26 May 2025 19:38:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove mistake

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 89:

> 87:   }
> 88:   if (event_id == JfrCPUTimeSampleEvent) {
> 89:     return _disabled_cpu_time_sample_throttler;

Why do you need to make a "disabled" throttler? Shouldn't the rate limiting always be done by the arguments given to `timer_create`? The actual JFR throttling mechanism used by `ObjectAllocationSample` doesn't really fit this use-case anyway since you can already pre-determine the rate at which events are emitted (while with `ObjectAllocationSample` you can't).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107808894

From jbechberger at openjdk.org  Mon May 26 20:07:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 20:07:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
 <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>
Message-ID: <bV7g_mEAOh_hC2XVWiACfk0DbNtEU4pD2Py5Q_-Rli4=.09a041e8-e268-45d9-85cf-9f261a13b457@github.com>

On Mon, 26 May 2025 19:58:26 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove mistake
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 89:
> 
>> 87:   }
>> 88:   if (event_id == JfrCPUTimeSampleEvent) {
>> 89:     return _disabled_cpu_time_sample_throttler;
> 
> Why do you need to make a "disabled" throttler? Shouldn't the rate limiting always be done by the arguments given to `timer_create`? The actual JFR throttling mechanism used by `ObjectAllocationSample` doesn't really fit this use-case anyway since you can already pre-determine the rate at which events are emitted (while with `ObjectAllocationSample` you can't).

This just makes the code simpler and avoids two additional checks on the throttler hot-path. The _disabled_cpu_time_sample_throttler is like `nullptr` but without the `nullptr` check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2107813533

From jbechberger at openjdk.org  Mon May 26 20:57:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 20:57:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d49b0084..d91f5672

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/25302

From zgu at openjdk.org  Tue May 27 01:04:55 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 27 May 2025 01:04:55 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v5]
In-Reply-To: <hJNvoBbNNpd4REHJsIBqEnvub2hFo6rugJQeHFc1Zno=.1d60da72-8760-48d3-947c-b1c9c8e4a7e6@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
 <-k-DamMcH1pZ4vSAkWjhlM5PD777oPKlkrX0JK2SsSk=.de6913a9-3e2f-4cc5-bc53-e251c82ed78d@github.com>
 <hJNvoBbNNpd4REHJsIBqEnvub2hFo6rugJQeHFc1Zno=.1d60da72-8760-48d3-947c-b1c9c8e4a7e6@github.com>
Message-ID: <g7KO1PP_k4tpK3U60yWOR0O7M2oouQl0rXJ3bDX76I4=.0eebf6d3-cc60-49e6-a825-1d78dda14671@github.com>

On Sun, 18 May 2025 15:21:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 404:
>> 
>>> 402:     collect_at_safepoint(!should_run_young_gc);
>>> 403: 
>>> 404:     if (is_gc_overhead_limit_reached()) {
>> 
>> Maybe want to adopt current algorithm, start to clear soft references when approaching gc overhead limit?
>> Running a full gc and clearing all soft references without retrying allocation and throws OOM, seems a bit harsh.
>> 
>> People still use soft references for caches, reclaim soft references could potentially free large amount of memory.
>
> Revised a bit; the limitation of what we have on master is that it doesn't detect gc-overhead for young-gcs. If many young-gcs are run, gc-overhead checking should kick in as well.

I wonder if you should try `expand_heap_and_allocate()` under `_is_heap_almost_full` situation as well.  I am afraid that it might throw OOM before heap is fully expanded again, because compact GC does not expand heap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2107963971

From jsikstro at openjdk.org  Tue May 27 07:02:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 27 May 2025 07:02:04 GMT
Subject: RFR: 8356848: Separate Metaspace and GC printing [v5]
In-Reply-To: <mTuJ6-rrpsc81IYMSZ7r3bPpNZwkccjojFDnrchjDnI=.ef855079-34f1-498d-ac9e-43bc95246b6f@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
 <WE2KdgDnKo_otVpnOILVQUjqeOFEKbctYmsAeXwUP_M=.b7b086ee-5cc6-44ff-96e0-fe3b580b2ca8@github.com>
 <mTuJ6-rrpsc81IYMSZ7r3bPpNZwkccjojFDnrchjDnI=.ef855079-34f1-498d-ac9e-43bc95246b6f@github.com>
Message-ID: <4V4E8FS8SBmH9GFYr2LZOl90Ktio1sXTkKR43L1osLU=.2549b4ee-a8cb-41a1-a7c4-b4a11f3fa218@github.com>

On Fri, 23 May 2025 04:36:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Feedback on Metaspace jcmd
>>  - Copyright years
>>  - Make HeapInfoTest.java more robust
>>  - Switch naming order of ring-buffer names
>
> Marked as reviewed by stuefe (Reviewer).

Thank you @tstuefe and @stefank for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25214#issuecomment-2911361909

From jsikstro at openjdk.org  Tue May 27 07:02:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 27 May 2025 07:02:04 GMT
Subject: Integrated: 8356848: Separate Metaspace and GC printing
In-Reply-To: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
References: <KxBUyRGN-GJGcTW903d2ScHOC48rqD6pX7xCskZE_GU=.487d5638-38b3-41d0-a1fb-edebe950aff6@github.com>
Message-ID: <f0arvWOKYP2aQhVL8v9mhEqYEgX6gIL1hFwJst4odEk=.9d718f1e-c275-45cb-a4c7-7758b40657f2@github.com>

On Tue, 13 May 2025 14:10:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The goal of this RFE is to separate Metaspace printing from GC printing. The main reason Metaspace and GC printing is coupled the way it is right now is because historically, the permanent generation (PermGen), which was replaced by Metaspace, was part of the GC heap. Hence, it made sense to also print info about the PermGen when printing the GC heap.
> 
> With Metaspace replacing the PermGen, which uses memory that is separate from the GC heap, the coupling has become more loose, raising the question if Metaspace should be printed somewhere else (maybe when printing *other* Metaspace stuff?). A reason to still print Metaspace when printing the heap is that the GC is responsible for unloading classes and nmethods, which means it makes sense to print Metaspace information in connection to when a GC is performed.
> 
> To better reflect the current state of the JVM, I propse we make the following changes to separate Metaspace from GC printing:
> * Move Metaspace printing from HeapInfoDCmd to MetaspaceDCmd.
> * Move Metaspace printing from the "Heap:" section to "Metaspace:" section in vmError.cpp (hs_err files, the VM.info jcmd and -XX:+PrintVMInfoAtExit).
> * Use gc+exit instead of gc+heap+exit as tags for the LogTarget during exit printing to reflect that it's not only the heap being printed.
> * And the largest change in terms of LOC, separate Metaspace and GC Heap prints in the before/after GC invocation(s) printing. This is also recorded in a ring buffer, which is printed in vmError.cpp.
> 
> Testing:
> * GHA, Oracle's tier 1-4
> * Manuel inspection of printed content

This pull request has now been integrated.

Changeset: 85af573c
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85af573cb6b5063c24f1efcbfb80bbace2883c7c
Stats:     148 lines in 14 files changed: 60 ins; 31 del; 57 mod

8356848: Separate Metaspace and GC printing

Reviewed-by: stefank, stuefe

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

PR: https://git.openjdk.org/jdk/pull/25214

From ayang at openjdk.org  Tue May 27 07:16:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 May 2025 07:16:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v6]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <L1GpFBJNWTehI6h7wenUwiqsQll4w7bdZ6xJKr5fpsU=.54e20237-c8a6-453e-b191-13e67dd91b29@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/320e590b..872b18bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=04-05

  Stats: 12205 lines in 260 files changed: 7807 ins; 3245 del; 1153 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Tue May 27 07:16:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 May 2025 07:16:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v6]
In-Reply-To: <g7KO1PP_k4tpK3U60yWOR0O7M2oouQl0rXJ3bDX76I4=.0eebf6d3-cc60-49e6-a825-1d78dda14671@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <3l8x32wbOr2FZzLV3lYfSbch-6hlT1te0uZXUeQVAcQ=.3ff8422e-fc0a-492f-a6bc-0df6acbc9a66@github.com>
 <-k-DamMcH1pZ4vSAkWjhlM5PD777oPKlkrX0JK2SsSk=.de6913a9-3e2f-4cc5-bc53-e251c82ed78d@github.com>
 <hJNvoBbNNpd4REHJsIBqEnvub2hFo6rugJQeHFc1Zno=.1d60da72-8760-48d3-947c-b1c9c8e4a7e6@github.com>
 <g7KO1PP_k4tpK3U60yWOR0O7M2oouQl0rXJ3bDX76I4=.0eebf6d3-cc60-49e6-a825-1d78dda14671@github.com>
Message-ID: <vrxUqjZqpm1PhR6m-cqDWF9i2wOlCi0tChDHH4w6clE=.296b2bb6-427f-496d-9194-642ace3efa1c@github.com>

On Tue, 27 May 2025 01:02:22 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Revised a bit; the limitation of what we have on master is that it doesn't detect gc-overhead for young-gcs. If many young-gcs are run, gc-overhead checking should kick in as well.
>
> I wonder if you should try `expand_heap_and_allocate()` under `_is_heap_almost_full` situation as well.  I am afraid that it might throw OOM before heap is fully expanded again, because compact GC does not expand heap.

`expand_heap_and_allocate` is invoked in both situations; also, heap is expanded inside `summary_phase` in order to hold all live-objs inside old-gen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2108377133

From stefank at openjdk.org  Tue May 27 09:50:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 27 May 2025 09:50:51 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <IzNp_ZCY5a62WhQLkmA-xL8jQFfCVeptuOxKqP5rdcw=.924c3f27-869e-4792-ae25-bf4044893ee8@github.com>

On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Just a few drive-by questions:

1) Did you consider putting this implementation in another file, say threadServices.hpp or even its own file? I'm asking because javaClasses seems to have become a dumping ground for code that calls from Java code into the JVM. It would be nice if we could put features into files that are named after the feature.

2) Did you consider to put these OopHandle storages in something else than Universe::vm_globals()? We have, for example, ThreadService::_thread_service_storage.

src/hotspot/share/classfile/javaClasses.cpp line 69:

> 67: #include "oops/typeArrayOop.inline.hpp"
> 68: #include "prims/jvmtiExport.hpp"
> 69: #include "prims/jvmtiThreadState.hpp" // for JvmtiVTMSTransitionDisabler

Drive-by comment: these comments tend to become stale so I recommend that they are dropped from this PR
Suggestion:

#include "prims/jvmtiThreadState.hpp"

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

PR Review: https://git.openjdk.org/jdk/pull/25425#pullrequestreview-2870373652
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2108712946

From aturbanov at openjdk.org  Tue May 27 10:10:55 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 May 2025 10:10:55 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName()
In-Reply-To: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
Message-ID: <A6OHmDIJn7lmYleQZwTEW2LVPJS7BW9pilL0D93iah4=.c1586975-5e4d-40e1-aef2-c4725dee429f@github.com>

On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
> 
> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
> 
> Tested nsk/jdi test locally. Will do more thorough ci testing.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue002.java line 123:

> 121:             }
> 122:             thrRef.suspend();
> 123:             while(!thrRef.isSuspended()) {

Suggestion:

            while (!thrRef.isSuspended()) {

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue003.java line 156:

> 154:             }
> 155:             thrRef.suspend();
> 156:             while(!thrRef.isSuspended()) {

Suggestion:

            while (!thrRef.isSuspended()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25337#discussion_r2108785297
PR Review Comment: https://git.openjdk.org/jdk/pull/25337#discussion_r2108784987

From mgronlun at openjdk.org  Tue May 27 11:13:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 11:13:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:

> 172:   assert(request._sample_pc != nullptr, "invariant");
> 173:   assert(jt != nullptr, "invariant");
> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");

What?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2108902215

From stefank at openjdk.org  Tue May 27 11:28:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 27 May 2025 11:28:01 GMT
Subject: RFR: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
In-Reply-To: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
References: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
Message-ID: <YadPVf4pHnbTWCJpS9pvZrK3S2TxhI6x57hxysGsCPY=.18e00222-b262-4d60-aa97-13ad4b2824c1@github.com>

On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/jvmti`

Looks good (and probably trivial).

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25458#pullrequestreview-2870684713

From alanb at openjdk.org  Tue May 27 11:37:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 11:37:54 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <IzNp_ZCY5a62WhQLkmA-xL8jQFfCVeptuOxKqP5rdcw=.924c3f27-869e-4792-ae25-bf4044893ee8@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <IzNp_ZCY5a62WhQLkmA-xL8jQFfCVeptuOxKqP5rdcw=.924c3f27-869e-4792-ae25-bf4044893ee8@github.com>
Message-ID: <pfEHgim5CDMKh2NEsQWihUs7W-de_SB0MULZk3Ug8N8=.f7dfdb99-2a37-47ed-9608-75e59b169691@github.com>

On Tue, 27 May 2025 09:48:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 1. Did you consider putting this implementation in another file, say threadServices.hpp or even its own file? I'm asking because javaClasses seems to have become a dumping ground for code that calls from Java code into the JVM. It would be nice if we could put features into files that are named after the feature.

Alex can correct me but I think it started out here because of java_lang_Thread::async_get_stack_trace/GetStackTraceClosure. It has gone through a number of iterations and you are probably right that it would be better off in threadService or its own source file now.

> 2. Did you consider to put these OopHandle storages in something else than Universe::vm_globals()? We have, for example, ThreadService::_thread_service_storage.

That OopStorage is maintained in threadService.cpp so would be an option if the code moves.

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

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2912183841

From mgronlun at openjdk.org  Tue May 27 11:39:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 11:39:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 195:

> 193: 
> 194:     public boolean hasThreshold() {
> 195:         if (hasCutoff || isCPUTimeMethodSampling) {

This is not a duration event anymore, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2108950974

From jbechberger at openjdk.org  Tue May 27 12:01:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 12:01:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
Message-ID: <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>

On Tue, 27 May 2025 11:11:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:
> 
>> 172:   assert(request._sample_pc != nullptr, "invariant");
>> 173:   assert(jt != nullptr, "invariant");
>> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");
> 
> What?

I also call this method for native stack traces in my implementation. As I have to walk native stack traces at stackwalks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2108995311

From rvansa at openjdk.org  Tue May 27 12:12:17 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 12:12:17 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v9]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <8xwa4r_hvch_iGVZ8KCr1cgOIGUSoLLxG4pSS8SqDKo=.acebbace-2aad-4ab4-93ba-3e457fb4dd3b@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Add test for various field counts and binary search thresholds
 - Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/1795e4b9..dbee64a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=07-08

  Stats: 215 lines in 5 files changed: 187 ins; 4 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From rvansa at openjdk.org  Tue May 27 12:12:17 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 12:12:17 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
 <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>
Message-ID: <auYsaXE62mckXk1gYLSGvwiRVdl0N0ycwEYVwdZN_r8=.2c95a653-e810-4632-96d9-158b2411d68a@github.com>

On Sat, 24 May 2025 20:41:06 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add search table validation
>
> src/hotspot/share/oops/fieldInfo.cpp line 220:
> 
>> 218: }
>> 219: 
>> 220: #ifdef ASSERT
> 
> Thank you for adding this.
> 
> Suggest an additional check to validate the binary search:
> 
> For each name/sig pair in the field stream, call the lookup function (or its subroutine) and ensure that it steers to the right position in the field stream.

Done. This was really useful; I found a stupid error that caused reading in bad index if that was >= 256.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2109014830

From rvansa at openjdk.org  Tue May 27 12:14:56 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 12:14:56 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <V3FJqoVvaJIb3VzB5-2H5a97UiCgwMSUa-UdPzquGj4=.e259b11b-a3f3-4f68-a33e-6e2033a5e7c5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
 <VUmpnGLXWCS2Fqv0rQoIJw1m0waLqQi2QgCZsDeMvaI=.6aab3cd5-e793-409c-abdd-9e71186d6e23@github.com>
 <V3FJqoVvaJIb3VzB5-2H5a97UiCgwMSUa-UdPzquGj4=.e259b11b-a3f3-4f68-a33e-6e2033a5e7c5@github.com>
Message-ID: <AjY1XrPXLFUHlJ7Z7UsUJHz2E6l54314SlJeL0t7EyQ=.b6682307-465d-4c73-9b63-cc1390268a3f@github.com>

On Sun, 25 May 2025 07:18:59 GMT, John R Rose <jrose at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.cpp line 252:
>> 
>>> 250: int FieldInfoReader::search_table_lookup(const Array<u1> *search_table, const Symbol *name, const Symbol *signature, ConstantPool *cp, int java_fields) {
>>> 251:   UNSIGNED5::Reader<const u1*, int> r2(_r.array());
>>> 252:   int low = 0, high = java_fields - 1;
>> 
>> This is probably correct, but I recommend a few changes:
>> A. add an assert `low <= high` at the beginning (defend against surprise `java_fields` number).
>> B. repeat the assert after each new calculation of high or low.
>> C. declare high and low and mid as `uint32_t` to prove overflow (UB) impossible without the need to reason about integral range
>
> I looked over the code base for other occurrences of binary search, and I see your code is not an outlier.
> 
> The tendency is to use int for high/mid/low, and there are cases where UB would be possible in the absence of extra knowledge about the possible ranges of the ints.  `InstanceKlass::quick_search` is especially scary, until one realizes that method lists are probably on the order of 2^16.  `vmSymbols::find_sid` is the same story; the number of symbols is much less than 2^30..
> 
> `GrowableArray::find_sorted` also uses int indexes, but uses a `uint` cast at just the right place when computing mid, to avoid UB, so can handle arrays sized near 2^31.
> 
> With those precedents, I'm not going to pick on this code here.  The recommended changes A/B/C are optional.
> 
> But I am going to think about what it would take to reduce the number of occurences of binary switch, and build a template that can re-implement at least some of them (probably including yours) with bullet-proof, unit-tested code.
> 
> Binary search over 3/4/5-byte packed records is easy, which is what you are doing here.  The use of shortened integers is clever.  I think that can be made a template also, and then used for more than one index, as I've observed before.
> 
> One good way to think about these variable-sized packed records is to treat them as physical `uint64_t` values, with high order zero bytes removed.  If you have a word or so of slop area at the bottom of the packed array, you can load 1..8 bytes in a single (misaligned) memory operation, loading garbage into unused bytes, and then using shift or mask to clear the garbage.  That may be faster than asking C++ to do a bunch of branchy logic and byte assembly on every access.  Loading an N-byte word is simply `w=*(uint64_t*)(p+N-8)>>(N*8)`.  Your packed structs have two fields x,y, but they can be reimagined as bitfields `x=w&((1<<xlen)-1)`, `y=w>>xlen`.  This would save half a byte per entry in your tables, on average, since you can often share a byte between the two fields.  And the decode logic would be simpler than the closure-based stuff you have now.
> 
> These thoughts are just another observation about the design space you are working in, not a request for changes, although I do think they would simplify your code (and make it more efficient).  This sort of careful design makes the most sense when packaged in a separate class or template,  that can be carefully reviewed and unit-tested in isolation.  If we were to refactor some old searchable...

I like the idea of mapping each element in the table as raw bits, though handling of access to the end of the array would be a bit inconvenient (or we would have to allocate a few extra bytes).

I've changed the algorithm to use unsigned integers; in fact I find a bit annoying that most of the indices used throughout the related code are signed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2109021670

From rvansa at openjdk.org  Tue May 27 12:22:54 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 12:22:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v9]
In-Reply-To: <8xwa4r_hvch_iGVZ8KCr1cgOIGUSoLLxG4pSS8SqDKo=.acebbace-2aad-4ab4-93ba-3e457fb4dd3b@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8xwa4r_hvch_iGVZ8KCr1cgOIGUSoLLxG4pSS8SqDKo=.acebbace-2aad-4ab4-93ba-3e457fb4dd3b@github.com>
Message-ID: <wv7B0V17aEjAN3_mk-9V4FcQnuPyuw5te2FKM_EbsNw=.4f927e87-19a8-4abe-9cc6-589fc56278ce@github.com>

On Tue, 27 May 2025 12:12:17 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for various field counts and binary search thresholds
>  - Address review comments

I've also added a test generating class with a different number of fields, though running it through the full range of fields (0-65535, though in practice the upper bound is rather 26k) would be excessive; even now it takes more than a minute on my machine.
Also, I realize that varying the number of fields does not result in full coverage of possible stream sizes; per-field records have probably rather uniform lengths.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2912299353

From mgronlun at openjdk.org  Tue May 27 14:16:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 14:16:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <a7YIW_NTpUuJR96eQ7a6AOa9Wk8zs-4MsbtbzrhnLfE=.30a02b7e-8bfd-4ea9-a256-80f5a9e7ad3d@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java line 54:

> 52: interface B3 {}
> 53: 
> 54: >>>>>>>> bbceab072555d5e2f5d3e99ae07a5ca5e909d7dc:test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java

merge error?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109322448

From mgronlun at openjdk.org  Tue May 27 14:21:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 14:21:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:

> 34: #include "runtime/mutexLocker.hpp"
> 35: 
> 36: #ifdef LINUX

Can things now be fwd declared in the .hpp and includes move to the .cpp instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109331738

From ayang at openjdk.org  Tue May 27 14:45:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 May 2025 14:45:34 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v7]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <AjURvsb7RFjWNJnXWYdATWHDZyBJs4DhzD9QZjg7sUA=.90d70434-9460-4bab-bfb0-cd2e952a2238@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - pgc-size-policy

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=06
  Stats: 4367 lines in 31 files changed: 522 ins; 3446 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From jbechberger at openjdk.org  Tue May 27 14:46:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 14:46:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
Message-ID: <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>

On Tue, 27 May 2025 14:17:46 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:
> 
>> 34: #include "runtime/mutexLocker.hpp"
>> 35: 
>> 36: #ifdef LINUX
> 
> Can things now be fwd declared in the .hpp and includes move to the .cpp instead?

No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?

> test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java line 54:
> 
>> 52: interface B3 {}
>> 53: 
>> 54: >>>>>>>> bbceab072555d5e2f5d3e99ae07a5ca5e909d7dc:test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java
> 
> merge error?

good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109398525
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109395879

From shade at openjdk.org  Tue May 27 14:48:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 14:48:02 GMT
Subject: RFR: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
In-Reply-To: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
References: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
Message-ID: <cjBJBiNh3ryJ1WI5QdYsyxlYXsKTIjyGX-U17wRaHv4=.f1c81edd-c9b0-435e-a57a-f71a31c01ca9@github.com>

On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/jvmti`

Thanks! Integrating now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25458#issuecomment-2912787135

From shade at openjdk.org  Tue May 27 14:48:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 14:48:03 GMT
Subject: Integrated: 8357800: Initialize JvmtiThreadState bool fields with bool
 literals
In-Reply-To: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
References: <12b14xHX7mPHyE6VRhbuxe3K5ZXnUk3O63O8fJHr5eU=.841b2007-3e82-4538-91cb-a78536c5c97e@github.com>
Message-ID: <qXzzlSn84yyms6Yw1s3-AxTpRDrtqKHFV_ntdxjzFY0=.074350c4-dbb8-40cf-bb20-3a36fb05b9d1@github.com>

On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good. But the initializations are still done with `0` literals. Even though it is benign, SonarCloud still complains about the intentionality of this initialization.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/jvmti`

This pull request has now been integrated.

Changeset: c2953774
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c29537740efb04e061732a700582d43b1956cff4
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8357800: Initialize JvmtiThreadState bool fields with bool literals

Reviewed-by: alanb, stefank

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

PR: https://git.openjdk.org/jdk/pull/25458

From ayang at openjdk.org  Tue May 27 14:58:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 May 2025 14:58:19 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v8]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <3ql7-GvvAqFRsM98wt_N9NaVvQHsEeWYu-4_ZG52X_Y=.ff5af1dc-7dfa-48a4-86be-3ea4a287a5ba@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  merge-fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/09fdd8c6..702fadc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=06-07

  Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From mgronlun at openjdk.org  Tue May 27 16:23:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:23:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
Message-ID: <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>

On Tue, 27 May 2025 14:44:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:
>> 
>>> 34: #include "runtime/mutexLocker.hpp"
>>> 35: 
>>> 36: #ifdef LINUX
>> 
>> Can things now be fwd declared in the .hpp and includes move to the .cpp instead?
>
> No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?

It can be a timer_t*

Then it's fwd declarable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109643605

From joehw at openjdk.org  Tue May 27 16:27:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 27 May 2025 16:27:56 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <L9gE2vcTtRmCj8sVb2Mf80vASRun10hEhdF8OJDXDQs=.f32fe500-e46b-4bab-b73c-b78f80723449@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

java.xml changes look good to me. But as you already asked, the translation team owns most of these files.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2871771071

From mgronlun at openjdk.org  Tue May 27 16:31:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
Message-ID: <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>

On Tue, 27 May 2025 16:20:58 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?
>
> It can be a timer_t*
> 
> Then it's fwd declarable.

If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109654903

From jbechberger at openjdk.org  Tue May 27 16:31:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 16:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
Message-ID: <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>

On Tue, 27 May 2025 16:27:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It can be a timer_t*
>> 
>> Then it's fwd declarable.
>
> If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.

It seems to normally be a pointer. I'll try the forward declaration later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109658273

From jlu at openjdk.org  Tue May 27 16:34:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 16:34:52 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
Message-ID: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>

On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> @justin-curtis-lu Are these files handled by the translation team?

@magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913234396

From mgronlun at openjdk.org  Tue May 27 16:36:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:36:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
 <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
Message-ID: <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>

On Tue, 27 May 2025 16:29:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.
>
> It seems to normally be a pointer. I'll try the forward declaration later.

Don't worry if it's too hard. It would just be a nice thing to eliminate these special includes from the header file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109666735

From naoto at openjdk.org  Tue May 27 17:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:03:53 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913310841

From amenkov at openjdk.org  Tue May 27 19:02:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 19:02:04 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <fyfXoqa91NWEG7o9O-qDvtn3r7AvYmaDQaq0xq9yNyI=.daf838b9-8006-4c7b-b11b-59885cab6748@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <fyfXoqa91NWEG7o9O-qDvtn3r7AvYmaDQaq0xq9yNyI=.daf838b9-8006-4c7b-b11b-59885cab6748@github.com>
Message-ID: <v2RqCCB6IrwXImVDGSy1-X2kCVuYWgKGX_kHBC2yPIg=.eed64fbd-a436-4a46-be19-059bfd5dcd5a@github.com>

On Sun, 25 May 2025 13:12:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> src/hotspot/share/classfile/javaClasses.cpp line 2241:
> 
>> 2239: }
>> 2240: 
>> 2241: class jdk_internal_vm_ThreadLock: AllStatic {
> 
> A bit unusual to declare class for java class in the cpp file - all others are declared in the hpp file.

`jdk_internal_vm_ThreadLock` and `jdk_internal_vm_ThreadSnapshot` classes are "local", they are used  only for `dump_to_file` diagnostic command, so I decide to not pollute javaClasses.hpp and initialize them on demand (most other classes are initialized on VM startup or read from cds)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2109950821

From amenkov at openjdk.org  Tue May 27 19:05:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 19:05:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <IzNp_ZCY5a62WhQLkmA-xL8jQFfCVeptuOxKqP5rdcw=.924c3f27-869e-4792-ae25-bf4044893ee8@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <IzNp_ZCY5a62WhQLkmA-xL8jQFfCVeptuOxKqP5rdcw=.924c3f27-869e-4792-ae25-bf4044893ee8@github.com>
Message-ID: <gUHdY9fxcHhqVUglFkB7rhzLNNJiDa2B3vmuhwfQsTI=.79a59138-d1e9-425a-90e3-ce95df25c2a8@github.com>

On Tue, 27 May 2025 09:48:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Just a few drive-by questions:
> 
>     1. Did you consider putting this implementation in another file, say threadServices.hpp or even its own file? I'm asking because javaClasses seems to have become a dumping ground for code that calls from Java code into the JVM. It would be nice if we could put features into files that are named after the feature.
> 
>     2. Did you consider to put these OopHandle storages in something else than Universe::vm_globals()? We have, for example, ThreadService::_thread_service_storage.

My concern about threadServices and _thread_service_storage was it's initialized conditionally. But now I see that they are always initialized. I'll try to move the stuff to threadServices.hpp/.cpp

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

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2913633174

From rvansa at openjdk.org  Tue May 27 21:45:34 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 21:45:34 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v10]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <Apl20iUGY17WwNo88xmGho8hney439e1ktp3f-PpQXE=.19aa088c-3b84-45ec-842c-0d50af21f6f2@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Refactor out PackedTable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/dbee64a7..8c2c8334

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=08-09

  Stats: 343 lines in 4 files changed: 247 ins; 75 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From rvansa at openjdk.org  Tue May 27 21:47:53 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 21:47:53 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v8]
In-Reply-To: <xZjfR4r5VoILZhXZCkcBH-lB2AgOe-Z-2LoThuYcFsQ=.84fd9e63-c60b-4938-b22a-87cf12d95212@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <YCXZKx5URsJ3XedhQPPYWU37lKKfNkoH9AqXWeufGmM=.49dbef5f-80ef-49f8-b064-e8345ffe0a59@github.com>
 <xZjfR4r5VoILZhXZCkcBH-lB2AgOe-Z-2LoThuYcFsQ=.84fd9e63-c60b-4938-b22a-87cf12d95212@github.com>
Message-ID: <OvNLpsEgguBDWP1A8X2uqll0H1Kbo-c4OhK3zGjYi0s=.74474a9f-696f-45a6-a1ca-703dbf784628@github.com>

On Sat, 24 May 2025 20:09:02 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add search table validation
>
> That said, I'm looking at your validation logic to see if a gtest can be deferred until the logic is fully factored. A stress mode test would do it for now.

@rose00 OK, so I have refactored out the `PackedTable` that now hosts the logic for packing two `uint32_t` values with arbitrary number of bits into a record, and binary search using custom comparator. Haven't added any gtests to test the functionality independently, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2914182870

From iveresov at openjdk.org  Tue May 27 21:57:11 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 27 May 2025 21:57:11 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v25]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <BNnXFAQOuJa50ESLyaAIafEUWSGj0DCtfJjr2OrDSsA=.d8f1bc0f-ae4c-4235-aa28-41959eb75684@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:

 - Merge branch 'master' into pp2
 - Missing part of the merge
 - Merge branch 'master' into pp2
 - Merge branch 'master' into pp2
 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform
 - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - Merge branch 'master' into pp2
 - Address Ioi's comments
 - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368

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

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=24
  Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From amenkov at openjdk.org  Tue May 27 22:48:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 22:48:15 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  move to ThreadService

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/bb9f7372..77489f3a

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

  Stats: 955 lines in 7 files changed: 491 ins; 461 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From amenkov at openjdk.org  Tue May 27 22:50:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 22:50:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <phW2tVQHbMdpEBbqTQ1CkSSi6Y7aNvtpWFRzRz_vy4s=.d8ee4e43-04b9-4da2-9fb8-abf74797cdba@github.com>

On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

- moved implementation from javaClasses to threadServices;
- used ThreadService OopStorage instead of vm_global;
- fixed minimalVM build (Thread.dump_to_file command is not registered for builds without JVMTI);

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

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2914359734

From amenkov at openjdk.org  Tue May 27 23:17:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 23:17:55 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default
In-Reply-To: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
Message-ID: <bgBTv-RD2K5WBgikLMKSUBDcCZG8IGlYIJReTlPjYqo=.41180c3c-d6d4-4d23-b265-b96882c74c99@github.com>

On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix turns on streaming output for attach operations.
> Change in HotSpotVirtualMachine.java sets attach client property.
> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
> 
> Testing: tier1..tier8

Ping. Looking for reviewers for the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25192#issuecomment-2914409840

From amenkov at openjdk.org  Tue May 27 23:25:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 May 2025 23:25:55 GMT
Subject: Integrated: 8357282: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after
 ClassNotFoundException
In-Reply-To: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
References: <nFTk_CrIMW0TXDfXq7uSlNaxuwoBqLbxm1ZxuP29MQc=.43a711d0-c3c5-4eaa-b2eb-eaa06cb2c454@github.com>
Message-ID: <D57dMe-xFi3FgqIAoIT1eVUXOLFNK4za0VVTOY5NoAI=.a0712582-0dea-44e4-93c4-aa5d8cbd96b6@github.com>

On Wed, 21 May 2025 20:17:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes failure of vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java test.
> The test was problem-listed in jdk 11 due intermittent timeouts, but in jdk15-16 changes in nsk framework made the test fail 100% (it wasn't noticed as the test was problemlisted)
> The problem is attach045 has "target" parameter which contain class name and arguments (all other tests have only class name), and value of the argument is passed in surrounding quotes, so target application fails with ClassNotFoundException.
> Now I cannot reproduce original test failure, so removing the test from problemlist

This pull request has now been integrated.

Changeset: c110623d
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c110623d38806c5170fbff640e77933dcef8981b
Stats:     8 lines in 2 files changed: 5 ins; 1 del; 2 mod

8357282: Test vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after ClassNotFoundException

Reviewed-by: lmesnik, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25366

From amenkov at openjdk.org  Wed May 28 01:25:27 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 01:25:27 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads [v2]
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <5NP780d1JpO89jffeMRPkT6Adqp29ttmwYKNP3gg18c=.2c3733d4-da7e-45eb-b37c-006de28783bf@github.com>

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25367/files
  - new: https://git.openjdk.org/jdk/pull/25367/files/3f559dc3..3a5edb18

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

  Stats: 41 lines in 1 file changed: 20 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25367/head:pull/25367

PR: https://git.openjdk.org/jdk/pull/25367

From amenkov at openjdk.org  Wed May 28 01:27:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 01:27:51 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads [v2]
In-Reply-To: <_6rWUi5bUBoF_LiPCbqhGfKeGswvqz-J2sLozEfjMWU=.f1088973-1005-4cbe-9b6b-a71d91817aea@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
 <_6rWUi5bUBoF_LiPCbqhGfKeGswvqz-J2sLozEfjMWU=.f1088973-1005-4cbe-9b6b-a71d91817aea@github.com>
Message-ID: <rKT3FL1IwXbG7hOJmdCOV1VF01TcA54jeWyb7r8nG3Q=.ab01e0a8-cb4b-45ca-a6a9-a540aa648f19@github.com>

On Sat, 24 May 2025 08:08:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/serviceability/dcmd/thread/ClassInitMonitorVThread.java line 71:
> 
>> 69:             Thread vthread2 = Thread.ofVirtual().name("Loader2").start(new Loader(loaderReady));
>> 70:             loaderReady.await();
>> 71:             Thread.sleep(100);
> 
> How reliable is this? With a debug build and -Xcomp/other options, then this might not long enough to observe "Loader 2" waiting for the class initializer.

I updated the test to do several retries. I think 20 seconds is enough for any build/options

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25367#discussion_r2110665847

From sspitsyn at openjdk.org  Wed May 28 03:31:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 03:31:52 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default
In-Reply-To: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
Message-ID: <0hu_9EF54wNHmxS5a0l_uynlRmGkxKVeIJCghNFbJ7E=.4a520beb-8e8b-42e9-822c-cab8294c5247@github.com>

On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix turns on streaming output for attach operations.
> Change in HotSpotVirtualMachine.java sets attach client property.
> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
> 
> Testing: tier1..tier8

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2873444194

From dholmes at openjdk.org  Wed May 28 08:06:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 May 2025 08:06:56 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
Message-ID: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>

On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move to ThreadService

Some initial drive-by comments ...

src/hotspot/share/classfile/javaClasses.cpp line 1875:

> 1873: 
> 1874: oop java_lang_Thread::park_blocker(oop java_thread) {
> 1875:   return java_thread->obj_field_acquire(_park_blocker_offset);

Where is the releasing store that pairs with this load-acquire?

src/hotspot/share/prims/jvmtiThreadState.hpp line 80:

> 78: // Virtual Thread Mount State Transition (VTMS transition) mechanism
> 79: //
> 80: class JvmtiVTMSTransitionDisabler : public AnyObj {

Why this change?

src/hotspot/share/services/threadService.cpp line 1170:

> 1168:   };
> 1169: 
> 1170:   Handle _java_thread;

Suggestion:

  Handle h_java_thread;

The use of the `h_` prefix for a variable that is a handle is not uncommon and makes it clearer it is a handle, especially when applying the `()` operator.

src/hotspot/share/services/threadService.cpp line 1189:

> 1187:     _thread_status(), _name(nullptr),
> 1188:     _locks(nullptr), _blocker(), _blocker_owner(nullptr) { }
> 1189:   virtual ~GetThreadSnapshotClosure() {

Suggestion:

    _locks(nullptr), _blocker(), _blocker_owner(nullptr) { 
  }
    
  virtual ~GetThreadSnapshotClosure() {

src/hotspot/share/services/threadService.cpp line 1203:

> 1201:   }
> 1202: 
> 1203:   bool read_reset_retry() {

What does the `read` mean in the name?

src/hotspot/share/services/threadService.cpp line 1206:

> 1204:     bool ret = _retry_handshake;
> 1205:     // If we re-execute the handshake this method need to return false
> 1206:     // when the handshake cannot be performed. (E.g. thread terminating)

Unclear what the comment means. The "retry" logic needs to be clearly explained somewhere.

src/hotspot/share/services/threadService.cpp line 1262:

> 1260:             // The first stage of async deflation does not affect any field
> 1261:             // used by this comparison so the ObjectMonitor* is usable here.
> 1262:             if (mark.has_monitor()) {

Does this depend on locking mode and non-compact-headers?

src/hotspot/share/services/threadService.cpp line 1434:

> 1432:   static Handle allocate(InstanceKlass* klass, TRAPS) {
> 1433:     init(klass, CHECK_NH);
> 1434:     return klass->allocate_instance_handle(CHECK_NH);

Suggestion:

    return klass->allocate_instance_handle(CHECK_NH);

Suggestion:

    Handle h_k = klass->allocate_instance_handle(CHECK_NH);
    return h_k;

You can't use `CHECK` on a `return` statement.

src/hotspot/share/services/threadService.cpp line 1528:

> 1526:   // StackTrace
> 1527:   InstanceKlass* ste_klass = vmClasses::StackTraceElement_klass();
> 1528:   assert(ste_klass != nullptr, "must be loaded in 1.4+");

Suggestion:

  assert(ste_klass != nullptr, "must be loaded");

The 1.4+ is not relevant these days

src/hotspot/share/services/threadService.cpp line 1531:

> 1529:   if (ste_klass->should_be_initialized()) {
> 1530:     ste_klass->initialize(CHECK_NULL);
> 1531:   }

Is this actually necessary? Doesn't this klass always get initialized as part of VM initialization?

src/hotspot/share/services/threadService.cpp line 1560:

> 1558:   // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace)
> 1559:   // to properly initialize STE.
> 1560:   {

Why the additional block scope?

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

PR Review: https://git.openjdk.org/jdk/pull/25425#pullrequestreview-2873829619
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111086253
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111089461
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111102216
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111108369
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111110893
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111112004
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111195897
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111202668
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111206814
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111207890
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111210020

From sspitsyn at openjdk.org  Wed May 28 08:06:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 08:06:58 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
Message-ID: <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>

On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move to ThreadService

src/hotspot/share/services/threadService.cpp line 1160:

> 1158: 
> 1159:     Type _type;
> 1160:     OopHandle _obj;

Nit: Short comments for `_depth` and `_obj` fields (lines: 1142, 1144, 1160) would be nice to have.

src/hotspot/share/services/threadService.cpp line 1172:

> 1170:   Handle _java_thread;
> 1171:   JavaThread* _thread;
> 1172:   int _depth;

Nit: This naming is confusing and not consistent with naming in JVMTI and other places.
The name `java_thread` is normally used for a `JavaThread*` object.
I would suggest to make it like this:
  Handle _thread_h;         // (or _thread_oop_h, or thread_obj_h)
  JavaThread* _java_thread;

src/hotspot/share/services/threadService.cpp line 1180:

> 1178:   GrowableArray<OwnedLock>* _locks;
> 1179:   Blocker _blocker;
> 1180:   OopHandle _blocker_owner;

Nit: Some short comments explaining the fields would be nice to have, at least for `_depth`, `_retry_handshake`, `_locks`, `_blocker` and `_blocker_owner`.

src/hotspot/share/services/threadService.cpp line 1317:

> 1315:         const ContinuationEntry* ce = _thread->vthread_continuation();
> 1316:         if (ce == nullptr || ce->cont_oop(_thread) != java_lang_VirtualThread::continuation(_java_thread())) {
> 1317:           // TODO: handle

Q: What `TODO` is expected here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111158038
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2110831057
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2110834293
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111194148

From sspitsyn at openjdk.org  Wed May 28 08:09:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 08:09:52 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
Message-ID: <8TB8Q4R2r-Vamr_o8cfTZ_AoStHDeRTeC_urrpn8z30=.239f8e49-04b8-4278-badf-004a32c32951@github.com>

On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move to ThreadService

src/hotspot/share/services/threadService.cpp line 39:

> 37: #include "oops/objArrayKlass.hpp"
> 38: #include "oops/objArrayOop.inline.hpp"
> 39: #include "oops/oop.inline.hpp"

I guess, the following include is also needed:

#include "oops/method.hpp"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111220227

From sspitsyn at openjdk.org  Wed May 28 08:21:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 08:21:51 GMT
Subject: RFR: 8357673: remove test
 serviceability/jvmti/vthread/TestPinCaseWithCFLH
In-Reply-To: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
References: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
Message-ID: <bfG_YbE73skeRSo9x9J5TgfGRWxW3yckIdnPustyG8M=.31e5f5c7-417a-43f0-a1eb-08b3ed187cff@github.com>

On Fri, 23 May 2025 20:50:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test `test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` was contributed by an external contributor to exercise the `-Djdk.tracePinnedThreads=full` system property when a `javaagent` was involved. The `jdk.tracePinnedThreads` system property is no longer supported by Virtual Threads implementation in mainline. That system property was dropped as part of https://github.com/openjdk/jdk/pull/21565 in JDK 24.
> This update removes the test which is not needed anymore.

Alex and Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25424#issuecomment-2915411351

From kevinw at openjdk.org  Wed May 28 09:10:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 28 May 2025 09:10:54 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
Message-ID: <qGbXutAj21phe3pssGvJxkjdwbehDdQlLYYWHVoBLeY=.e7fd395b-5764-4eee-888b-4ac927049007@github.com>

On Thu, 22 May 2025 14:09:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into statsampler-removal
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

Hi, looks good.
If we are removing things from jcmd PerfCounter.print output, that could feature in the release note that you have planned.  Anybody expecting these counters using jcmd PerfCounter.print or other methods, may not know that they are related to StatSampler and would not realise from the title that this is a relevant change.

$ jcmd 203133 PerfCounter.print | grep hrt
sun.os.hrt.frequency=1000000000
sun.os.hrt.ticks=132389861230

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

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2915558106

From jbechberger at openjdk.org  Wed May 28 09:14:03 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:14:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
 <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
 <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>
Message-ID: <VKtJxfbq_wppvFd1-FN-psD4E_q99-n9VxCTaUu_2Uc=.da074f23-2836-4c4e-a0e5-e86707f64e75@github.com>

On Tue, 27 May 2025 16:34:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It seems to normally be a pointer. I'll try the forward declaration later.
>
> Don't worry if it's too hard. It would just be a nice thing to eliminate these special includes from the header file.

The signal.h is apparently included in the `globaldefinitions_gcc`, so no need to include it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2111351553

From mgronlun at openjdk.org  Wed May 28 09:14:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 09:14:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <Nkmt86d0RFZsvPU6Y_tpYDB6UUKL4iHtGAp99VYEDu8=.e29bdafa-78bf-4fcc-92a6-7bd33fc43273@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 89:

> 87: 
> 88: #ifdef LINUX
> 89:   timer_t* _cpu_timer = nullptr;

initialize in initializer-list, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109668742

From jbechberger at openjdk.org  Wed May 28 09:32:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:32:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>
Message-ID: <13TF0svCL8PZgux4OPldxyf6kx-4PI3Yqg05aNTdOAE=.74ce218e-84d1-4a30-a8b2-b5e661ba2476@github.com>

On Tue, 27 May 2025 11:36:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 195:
> 
>> 193: 
>> 194:     public boolean hasThreshold() {
>> 195:         if (hasCutoff || isCPUTimeMethodSampling) {
> 
> This is not a duration event anymore, right?

Yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2111388369

From alanb at openjdk.org  Wed May 28 09:39:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 09:39:55 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <5eja36GwtLPqwerJOWLntBLTniWqF3v1ap-ODCxukRg=.03773d4a-ed4c-4e0c-92c4-1c2e78956207@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>
 <5eja36GwtLPqwerJOWLntBLTniWqF3v1ap-ODCxukRg=.03773d4a-ed4c-4e0c-92c4-1c2e78956207@github.com>
Message-ID: <0kbM-YDMy-otEFiYYZOWwOnACJk7qwMd4Fz_leg1cTs=.acb0acf5-7d4d-407d-ba23-49c7f5ac6789@github.com>

On Mon, 26 May 2025 16:06:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 186:
> 
>> 184:         Thread.State state = snapshot.threadState();
>> 185:         writer.println("#" + thread.threadId() + " \"" + snapshot.threadName()
>> 186:                 +  "\" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);
> 
> Suggestion:
> 
>                 + "" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);

okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2111404652

From alanb at openjdk.org  Wed May 28 09:39:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 09:39:59 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <GWWc2qqZtdhUizRtbUmyDwST8IWRMG5UJ-seFfOkmGA=.7fd36b7c-81cf-4c08-8ca9-e68fa725d3d2@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <GWWc2qqZtdhUizRtbUmyDwST8IWRMG5UJ-seFfOkmGA=.7fd36b7c-81cf-4c08-8ca9-e68fa725d3d2@github.com>
Message-ID: <rdeXc0OTj_vCvHfD2NMGBosqEXXhnj0RMJG1Lry0sW8=.3e491346-39ad-4932-9de5-d82f743c7c42@github.com>

On Sat, 24 May 2025 09:37:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 83:
> 
>> 81:                 sb.append(System.currentTimeMillis());
>> 82:                 String s = sb.toString();
>> 83:                 ref.set(s);
> 
> Suggestion:
> 
>                 ref.set(
>                         new StringBuffer()
>                                 .append(System.currentTimeMillis())
>                                 .toString());

This looks a lot less readable so I don't think we should change it.

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 385:
> 
>> 383:             if (name.length() > 0) {
>> 384:                 sb.append(",");
>> 385:                 sb.append(name);
> 
> Suggestion:
> 
>                 sb.append(",")
>                   .append(name);

okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2111405917
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2111404857

From jbechberger at openjdk.org  Wed May 28 09:40:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:40:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v18]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <xZ11RXOveumCsU4jiaGffoqAFuLRIb76Xm6fjoyKkrw=.2df6b01f-3186-4f39-967b-79a1cda9c25c@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Tiny fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d91f5672..298ea428

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=16-17

  Stats: 77 lines in 6 files changed: 5 ins; 60 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 09:50:45 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:50:45 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v19]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Y7B2yGEeYJiqxZ85INmSF7wvQ373cADOqTs1o88rmvM=.a894babd-e82a-4ef8-b0d5-dc97d37c9aba@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Tiny fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/298ea428..7c3ec247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=17-18

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

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 10:32:20 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 10:32:20 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v20]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HMOe2arlJm-rSgF5a5xFzv3WkL86y2AwUpYNhi5k9EU=.c77d8203-c4c0-4261-bfac-3814f3b125fe@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix builds on non Linux platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/7c3ec247..ca6debcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=18-19

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From sspitsyn at openjdk.org  Wed May 28 10:44:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 10:44:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
Message-ID: <f13aDzfDaCxfCb-aAvpjukXhaEsR2DifVLomOWpsF8o=.cb2796fc-321f-4c2b-b8f9-99f962eddb39@github.com>

On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move to ThreadService

src/hotspot/share/prims/jvm.cpp line 2968:

> 2966:   oop snapshot = VMThreadSnapshot::get_thread_snapshot(jthread, THREAD);
> 2967:   return JNIHandles::make_local(THREAD, snapshot);
> 2968: #elif

Q: should it be `#else` instead of `#elif`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111519744

From cnorrbin at openjdk.org  Wed May 28 11:09:59 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 28 May 2025 11:09:59 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <qGbXutAj21phe3pssGvJxkjdwbehDdQlLYYWHVoBLeY=.e7fd395b-5764-4eee-888b-4ac927049007@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
 <qGbXutAj21phe3pssGvJxkjdwbehDdQlLYYWHVoBLeY=.e7fd395b-5764-4eee-888b-4ac927049007@github.com>
Message-ID: <N0DqcDI8Hf8nY844xcAUxzsUQ0eklHbcFGruJ29uCx8=.d2f976c2-77bf-41ef-965e-7ecc415c427c@github.com>

On Wed, 28 May 2025 09:08:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi, looks good.
> If we are removing things from jcmd PerfCounter.print output, that could feature in the release note that you have planned. Anybody expecting these counters using jcmd PerfCounter.print or other methods, may not know that they are related to StatSampler and would not realise from the title that this is a relevant change.

Thank you. I will add that to the release note, along with text on how to calculate it instead using offsets (similar to what I did with the jstat counter)

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

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2915907228

From sspitsyn at openjdk.org  Wed May 28 11:40:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 11:40:55 GMT
Subject: Integrated: 8357673: remove test
 serviceability/jvmti/vthread/TestPinCaseWithCFLH
In-Reply-To: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
References: <9Ivd8PtgLCrDpa7d0kIpDOaZE229RZWZCEDN36Rcp_g=.2b1bb224-5c2e-4dfb-a525-05e3e2598b6b@github.com>
Message-ID: <MpkbHVgPr1XQV9God-YkQ_Ajn5cSeV8Nr3-85rNnHsw=.64fc4553-2020-4985-b65f-9c37ae2fbe71@github.com>

On Fri, 23 May 2025 20:50:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test `test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` was contributed by an external contributor to exercise the `-Djdk.tracePinnedThreads=full` system property when a `javaagent` was involved. The `jdk.tracePinnedThreads` system property is no longer supported by Virtual Threads implementation in mainline. That system property was dropped as part of https://github.com/openjdk/jdk/pull/21565 in JDK 24.
> This update removes the test which is not needed anymore.

This pull request has now been integrated.

Changeset: f30e1541
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f30e15411f5c0fc90565dac19203fdc1ab43fd88
Stats:     77 lines in 1 file changed: 0 ins; 77 del; 0 mod

8357673: remove test serviceability/jvmti/vthread/TestPinCaseWithCFLH

Reviewed-by: amenkov, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/25424

From jsjolen at openjdk.org  Wed May 28 11:48:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 28 May 2025 11:48:53 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
Message-ID: <TQb2tjm6KeS2Dk4hmiy2WojfTwBCVxIxQd2wZQjEwRA=.eef86ccd-e428-45fd-8aa8-6e0c3ffac211@github.com>

On Thu, 22 May 2025 14:09:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into statsampler-removal
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

Thank you for the review, @kevinjwalls. Let's integrate it :-).

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24872#pullrequestreview-2874686378

From cnorrbin at openjdk.org  Wed May 28 11:51:53 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 28 May 2025 11:51:53 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
Message-ID: <MjInG9oOE9M4CD-8S7VhxoN3-IxOp2jYWGd9i0bojjU=.dc103f03-f7f9-4cc7-ab6b-cfb746c87d0a@github.com>

On Thu, 22 May 2025 14:09:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into statsampler-removal
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

Thank you everyone for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2916013283

From duke at openjdk.org  Wed May 28 11:51:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 11:51:53 GMT
Subject: RFR: 8241678: Remove PerfData sampling via StatSampler [v4]
In-Reply-To: <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
 <x7rXIMWEr_sBGfQmC0A0LDK1xhOgT11nHlWvlFJXA6k=.d17a1956-d28b-4d59-b426-89b054616f1a@github.com>
Message-ID: <AC-K49PF8IeaFahqhePT0h67qKILBATY_JTDskn2GZQ=.5e44a77b-1fb4-4292-bc56-132479cde3d3@github.com>

On Thu, 22 May 2025 14:09:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into statsampler-removal
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

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

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

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2916015185

From cnorrbin at openjdk.org  Wed May 28 12:03:03 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 28 May 2025 12:03:03 GMT
Subject: Integrated: 8241678: Remove PerfData sampling via StatSampler
In-Reply-To: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
References: <qbTsdRP_DcNZ-p4HZtdMqquZZlUGtV26GpffR5ap5ko=.f53d43a9-0c47-470c-9cdb-7f1d9814e1d7@github.com>
Message-ID: <BErBCJDi16eM29Y8eXTUgi8berQFi5s5afzKVC9b25M=.86d12ec9-721d-43c9-8ba9-34dd6d35d208@github.com>

On Fri, 25 Apr 2025 10:38:39 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` ? an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
> 
> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
> 
> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.

This pull request has now been integrated.

Changeset: 6ebae6cd
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ebae6cded49f9b0b0d42899af3303647eca7848
Stats:     864 lines in 25 files changed: 150 ins; 655 del; 59 mod

8241678: Remove PerfData sampling via StatSampler

Reviewed-by: jsjolen, ayang

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

PR: https://git.openjdk.org/jdk/pull/24872

From alanb at openjdk.org  Wed May 28 13:01:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 13:01:58 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
Message-ID: <7I-QS9aIISJbsTz7s9wT1I8EhWbsgxcM_l_CKqFnM2M=.2cf0303f-2b0e-406b-9fba-ac75a20bce59@github.com>

On Wed, 28 May 2025 07:01:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 80:
> 
>> 78: // Virtual Thread Mount State Transition (VTMS transition) mechanism
>> 79: //
>> 80: class JvmtiVTMSTransitionDisabler : public AnyObj {
> 
> Why this change?

It's used by VMThreadSnapshot::get_thread_snapshot. The transition disabling support is currently in the jvmti code. I think this is the first usage in a handshake op that isn't supporting a JVMTI function. Maybe in the future this could be separated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111794761

From alanb at openjdk.org  Wed May 28 13:37:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 13:37:55 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
Message-ID: <A7Fpb0bKWQfoAQsq5A4RM8jmWHAfu4oQB4neob8_MXs=.fd700eef-954d-4b5d-9b62-68afca0129d3@github.com>

On Wed, 28 May 2025 06:59:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/classfile/javaClasses.cpp line 1875:
> 
>> 1873: 
>> 1874: oop java_lang_Thread::park_blocker(oop java_thread) {
>> 1875:   return java_thread->obj_field_acquire(_park_blocker_offset);
> 
> Where is the releasing store that pairs with this load-acquire?

Thread.parkBlocker is declared volatile but all access is done in opaque mode, so maybe this should MO_RELAXED?

In any case, I think we might have to drop the sampling of exclusiveOwnerThread for now. This can only be tested to see if it's the current thread, and only after a volatile-state of the state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2111943610

From kvn at openjdk.org  Wed May 28 14:11:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 28 May 2025 14:11:16 GMT
Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
 [v25]
In-Reply-To: <BNnXFAQOuJa50ESLyaAIafEUWSGj0DCtfJjr2OrDSsA=.d8f1bc0f-ae4c-4235-aa28-41959eb75684@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <BNnXFAQOuJa50ESLyaAIafEUWSGj0DCtfJjr2OrDSsA=.d8f1bc0f-ae4c-4235-aa28-41959eb75684@github.com>
Message-ID: <MGDzZ3qgJ_DA6fD5bh6Qjoej5xIuLF9dwM_JbHT0xLg=.e8a0ec14-d825-41be-9418-c4a74c958aea@github.com>

On Tue, 27 May 2025 21:57:11 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into pp2
>  - Missing part of the merge
>  - Merge branch 'master' into pp2
>  - Merge branch 'master' into pp2
>  - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform
>  - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache
>  - Merge branch 'master' into pp2
>  - Address Ioi's comments
>  - Merge branch 'master' into pp2
>  - Address Ioi's comments
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368

Re-approved

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2875268813

From iveresov at openjdk.org  Wed May 28 15:18:03 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 28 May 2025 15:18:03 GMT
Subject: Integrated: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <kMl5qsaunGAg5wJdUzXeEPpScNroCoq7KoDTYAySFrc=.32eed349-6db7-4fca-a459-c2f250495bd2@github.com>

On Fri, 25 Apr 2025 20:18:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

This pull request has now been integrated.

Changeset: e3f85c96
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3f85c961b4c1e5e01aedf3a0f4e1b0e6ff457fd
Stats:     3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod

8355003: Implement JEP 515: Ahead-of-Time Method Profiling

Co-authored-by: John R Rose <jrose at openjdk.org>
Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Co-authored-by: Ioi Lam <iklam at openjdk.org>
Co-authored-by: Vladimir Kozlov <kvn at openjdk.org>
Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: kvn, ihse, cjplummer, iklam

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

PR: https://git.openjdk.org/jdk/pull/24886

From lmesnik at openjdk.org  Wed May 28 15:24:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 28 May 2025 15:24:03 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v3]
In-Reply-To: <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>
Message-ID: <yl3OE6uSZ9EdepYmJu_Xa1U-ggIAEdZ_FyGjjV5ljBg=.85078e2c-601b-4d57-bde1-90171fa06e00@github.com>

On Fri, 23 May 2025 04:33:36 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8354475
>  - Update TestDockerMemoryMetricsSubgroup.java
>    
>    remove extra space
>  - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2875529614

From jbechberger at openjdk.org  Wed May 28 15:27:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 15:27:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v21]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HDnDGi516BVT8c8-bDmpYeTs80k937xo2RVXPi7pSv4=.bb01c91b-87f1-48d5-b1e9-1f08e1ff3d12@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:

 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix builds on non Linux platforms
 - Tiny fixes
 - Tiny fixes
 - Remove assertion
 - Remove mistake
 - Merge branch 'master' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix other platforms
 - Improve one warning
 - Fix MacOS build
 - ... and 79 more: https://git.openjdk.org/jdk/compare/e3f85c96...14f1d068

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=20
  Stats: 2339 lines in 45 files changed: 2164 ins; 159 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From duke at openjdk.org  Wed May 28 16:02:56 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 28 May 2025 16:02:56 GMT
Subject: Integrated: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <p7Y4qVlvRmJSi8Hp8C41Y56om-umXo98sgluEUpszwo=.c9ffeb7f-4ae1-413e-b1b6-822c8c950242@github.com>

On Mon, 28 Apr 2025 15:51:44 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

This pull request has now been integrated.

Changeset: e579cca6
Author:    PAWAN CHAWDHARY <pawan.chawdhary at oracle.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e579cca619147aa51563dc00f374e02db49e1238
Stats:     18 lines in 1 file changed: 18 ins; 0 del; 0 mod

8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

Reviewed-by: lmesnik, mseledtsov

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

PR: https://git.openjdk.org/jdk/pull/24930

From jbechberger at openjdk.org  Wed May 28 17:19:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 17:19:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v22]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <1IqxrA9yctj4oWW6HVBY1T6xzpgLc80f8ZYo088QAlE=.c99ef9df-563d-4b0b-bdb0-433f2e0022db@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Replace views with cpu-time-statistics view

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/14f1d068..4a2cbac3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=20-21

  Stats: 22 lines in 1 file changed: 0 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 17:57:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 17:57:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
Message-ID: <E6DVl6uikV7YtSz6hh_pbzcJQKZo-q9Q9cvYS2RH1uA=.e1b4a248-b466-4f08-b8f5-40c5211ee900@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.
> 
> I have a Mac, so I could not try it with an actual recording, but something like this:
> 
> ```
> [application.cpu-time-statistics]
> label = "CPU Time Samples Statistics"
> form = "COLUMN 'Successful Samples', 'Failed Samples', 'Total Samples', 'Lost Samples'
>         SELECT COUNT(S.startTime), COUNT(F.startTime), Count(A.startTime), SUM(L.lostSamples)
>         FROM 
>           CPUTimeSample AS S,
>           CPUTimeSample AS F,
>           CPUTimeSample AS A,
>           CPUTimeSampleLoss AS L
>         WHERE
>           S.failed = 'false' AND
>           F.failed = 'true'"
> ```

I implemented this now and removed the other statistics related views.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2917155602

From amenkov at openjdk.org  Wed May 28 18:18:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 18:18:56 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <7I-QS9aIISJbsTz7s9wT1I8EhWbsgxcM_l_CKqFnM2M=.2cf0303f-2b0e-406b-9fba-ac75a20bce59@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
 <7I-QS9aIISJbsTz7s9wT1I8EhWbsgxcM_l_CKqFnM2M=.2cf0303f-2b0e-406b-9fba-ac75a20bce59@github.com>
Message-ID: <dApBOWgC1qg8WAw1rsGcuSS2XyrEjQAG8VSsbWjqblM=.4d93c1ef-11b1-4df3-9c6a-3567b0f8103d@github.com>

On Wed, 28 May 2025 12:58:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.hpp line 80:
>> 
>>> 78: // Virtual Thread Mount State Transition (VTMS transition) mechanism
>>> 79: //
>>> 80: class JvmtiVTMSTransitionDisabler : public AnyObj {
>> 
>> Why this change?
>
> It's used by VMThreadSnapshot::get_thread_snapshot. The transition disabling support is currently in the jvmti code. I think this is the first usage in a handshake op that isn't supporting a JVMTI function. Maybe in the future this could be separated.

> Why this change?
To be more clear about the change:
We need JvmtiVTMSTransitionDisabler for virtual threads only, for platform threads handshake is enough. And currently for platform threads JvmtiVTMSTransitionDisabler disables all mount/unmount transitions (and I'd prefer to avoid this).
So we cannot create JvmtiVTMSTransitionDisabler on a stack (this is standard use scenario), but need to create it conditionally by `new`/`delete`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112491335

From amenkov at openjdk.org  Wed May 28 18:33:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 18:33:58 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
Message-ID: <GzQcbyzD7iy44JEXPD8HKldR9R-Xe28_XuyDU3re7l8=.d15c7345-242a-4fe6-b8cd-9b5483106c3f@github.com>

On Wed, 28 May 2025 07:07:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1170:
> 
>> 1168:   };
>> 1169: 
>> 1170:   Handle _java_thread;
> 
> Suggestion:
> 
>   Handle h_java_thread;
> 
> The use of the `h_` prefix for a variable that is a handle is not uncommon and makes it clearer it is a handle, especially when applying the `()` operator.

I'm going to rename the fields as Serguei suggested (so this will be `Handle _thread_h`)

> src/hotspot/share/services/threadService.cpp line 1203:
> 
>> 1201:   }
>> 1202: 
>> 1203:   bool read_reset_retry() {
> 
> What does the `read` mean in the name?

read and then reset the `retry` value (return old value)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112513006
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112517968

From shade at openjdk.org  Wed May 28 18:56:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 18:56:34 GMT
Subject: RFR: 8357999: SA: FileMapInfo.metadataTypeArray initialization issue
 after JDK-8355003
Message-ID: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>

SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 

Additional testing:
 - [x] Linux x86_64 server fastdebug, `serviceability/sa`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357999
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25507/head:pull/25507

PR: https://git.openjdk.org/jdk/pull/25507

From ayang at openjdk.org  Wed May 28 19:21:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 28 May 2025 19:21:53 GMT
Subject: RFR: 8357999: SA: FileMapInfo.metadataTypeArray initialization
 issue after JDK-8355003
In-Reply-To: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
References: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
Message-ID: <UyaCghqPUin6KypdZG20LliMS4Gfn_I37vP2rNCoWno=.197d737b-bee3-47ea-b6af-0af3f96cf359@github.com>

On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/sa`

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25507#pullrequestreview-2876180639

From amenkov at openjdk.org  Wed May 28 19:40:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 19:40:54 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <f13aDzfDaCxfCb-aAvpjukXhaEsR2DifVLomOWpsF8o=.cb2796fc-321f-4c2b-b8f9-99f962eddb39@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <f13aDzfDaCxfCb-aAvpjukXhaEsR2DifVLomOWpsF8o=.cb2796fc-321f-4c2b-b8f9-99f962eddb39@github.com>
Message-ID: <SsYnVpNyJ3gEN4zUep1HsiOf3cxnjgfQBY-ADUf93qc=.2ce52f00-f2c5-4709-a34c-bde5b0c12815@github.com>

On Wed, 28 May 2025 10:33:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/prims/jvm.cpp line 2968:
> 
>> 2966:   oop snapshot = VMThreadSnapshot::get_thread_snapshot(jthread, THREAD);
>> 2967:   return JNIHandles::make_local(THREAD, snapshot);
>> 2968: #elif
> 
> Q: should it be `#else` instead of `#elif`?

right. this breaks minimal build

> src/hotspot/share/services/threadService.cpp line 39:
> 
>> 37: #include "oops/objArrayKlass.hpp"
>> 38: #include "oops/objArrayOop.inline.hpp"
>> 39: #include "oops/oop.inline.hpp"
> 
> I guess, the following include is also needed:
> 
> #include "oops/method.hpp"

actually "oops/method.inline.hpp". Thanks

> src/hotspot/share/services/threadService.cpp line 1317:
> 
>> 1315:         const ContinuationEntry* ce = _thread->vthread_continuation();
>> 1316:         if (ce == nullptr || ce->cont_oop(_thread) != java_lang_VirtualThread::continuation(_java_thread())) {
>> 1317:           // TODO: handle
> 
> Q: What `TODO` is expected here?

actually it's unreachable. can be dropped

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112618339
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112539322
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112605468

From amenkov at openjdk.org  Wed May 28 19:40:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 28 May 2025 19:40:57 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
Message-ID: <_YHLhodQAHCVUc21EmfgWC4nOvVNQGky7lGeYTyufDU=.2af6d17b-05dd-49f8-a7f9-c9a2e654ce43@github.com>

On Wed, 28 May 2025 07:10:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1206:
> 
>> 1204:     bool ret = _retry_handshake;
>> 1205:     // If we re-execute the handshake this method need to return false
>> 1206:     // when the handshake cannot be performed. (E.g. thread terminating)
> 
> Unclear what the comment means. The "retry" logic needs to be clearly explained somewhere.

The logic comes from `java_lang_Thread::async_get_stack_trace()` (implementation of `java.lang.Thread.getStackTrace()`) I don't see why the handshake needs to be executed on JavaThread.

> src/hotspot/share/services/threadService.cpp line 1262:
> 
>> 1260:             // The first stage of async deflation does not affect any field
>> 1261:             // used by this comparison so the ObjectMonitor* is usable here.
>> 1262:             if (mark.has_monitor()) {
> 
> Does this depend on locking mode and non-compact-headers?

AFAIU locking mode should not be lightweight, but in the case mark.has_monitor() returns false, so no need to additional checks

> src/hotspot/share/services/threadService.cpp line 1531:
> 
>> 1529:   if (ste_klass->should_be_initialized()) {
>> 1530:     ste_klass->initialize(CHECK_NULL);
>> 1531:   }
> 
> Is this actually necessary? Doesn't this klass always get initialized as part of VM initialization?

I suppose it's not necessary, just for safety

> src/hotspot/share/services/threadService.cpp line 1560:
> 
>> 1558:   // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace)
>> 1559:   // to properly initialize STE.
>> 1560:   {
> 
> Why the additional block scope?

not needed anymore

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112569181
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112597974
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112616322
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2112616667

From iklam at openjdk.org  Wed May 28 22:22:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 May 2025 22:22:53 GMT
Subject: RFR: 8357999: SA: FileMapInfo.metadataTypeArray initialization
 issue after JDK-8355003
In-Reply-To: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
References: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
Message-ID: <VgEHw-M9MphUYhPZz3eo9QwREN_Y5kY96wBlmJBwV8c=.47ffb98b-e48a-47c7-85d4-34d06b753cc2@github.com>

On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/sa`

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25507#pullrequestreview-2876606308

From kvn at openjdk.org  Wed May 28 22:40:50 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 28 May 2025 22:40:50 GMT
Subject: RFR: 8357999: SA: FileMapInfo.metadataTypeArray initialization
 issue after JDK-8355003
In-Reply-To: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
References: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
Message-ID: <zD3nl3AWv9l8mOUPtOVwj1j8ZSVulvYkzcorNHkw5O8=.5e9800db-65e7-4fe5-be95-525d25753b0d@github.com>

On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/sa`

Good

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25507#pullrequestreview-2876627275

From sspitsyn at openjdk.org  Wed May 28 23:14:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 May 2025 23:14:50 GMT
Subject: RFR: 8357999: SA: FileMapInfo.metadataTypeArray initialization
 issue after JDK-8355003
In-Reply-To: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
References: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
Message-ID: <11-kYgYw9IrzkCs_Lr9fyjuPBoJayYYHVKb9CuoDNZ8=.ab4bed20-3b10-484f-a090-22452bc22651@github.com>

On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/sa`

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25507#pullrequestreview-2876666642

From amenkov at openjdk.org  Thu May 29 00:46:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 00:46:32 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v3]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <99yfgxPJn37JH0a6gS9yeIXPZSZhnVquOr-7k_7Xcls=.1771a0ee-515b-49ae-b909-8adfbce42fd7@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

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

 - Merge branch 'openjdk:master' into thread_dump
 - move to ThreadService
 - initial fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/77489f3a..ce7d4fa3

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

  Stats: 29059 lines in 599 files changed: 20212 ins; 5748 del; 3099 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From dholmes at openjdk.org  Thu May 29 00:52:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 May 2025 00:52:53 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v4]
In-Reply-To: <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
Message-ID: <G130a4rAH7XlliPQh3-cC9N-XyNf9QkO02DqroTqVts=.dfa39c7e-9b9a-4175-ae5b-c71e1bb777f3@github.com>

On Fri, 9 May 2025 22:34:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move other tier 4,5, etc tests to not use ClassReader
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Use classfile api instead of javac setting version
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - 8356548: Avoid using ASM to parse latest class files in tests

I do not know either ASM or the Classfile API in great depth so evaluating the conversion is difficult. That said it looks reasonable.

How have you validated the conversion process? Did you check that the Classfile API generated files match the ASM versions? I can imagine it would be very easy to make a mistake in the conversion process and still have the tests pass.

Thanks

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

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-2876764761

From amenkov at openjdk.org  Thu May 29 03:26:49 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:26:49 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:

 - removed retry_handshake logic
 - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
 - cleanup
 - renamed java_thread, thread_h
 - fixed minimal and zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/ce7d4fa3..ff334ab6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=02-03

  Stats: 112 lines in 4 files changed: 4 ins; 56 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From amenkov at openjdk.org  Thu May 29 03:32:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:32:54 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
Message-ID: <HyIziCAjYEh02jKlcf2kvnI6RF82l1cmacYKvGZZSdw=.20b4413d-e161-45cc-9f12-d281f9d082e7@github.com>

On Wed, 28 May 2025 03:47:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1172:
> 
>> 1170:   Handle _java_thread;
>> 1171:   JavaThread* _thread;
>> 1172:   int _depth;
> 
> Nit: This naming is confusing and not consistent with naming in JVMTI and other places.
> The name `java_thread` is normally used for a `JavaThread*` object.
> I would suggest to make it like this:
>   Handle _thread_h;         // (or _thread_oop_h, or thread_obj_h)
>   JavaThread* _java_thread;

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113105546

From amenkov at openjdk.org  Thu May 29 03:41:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:41:52 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <A7Fpb0bKWQfoAQsq5A4RM8jmWHAfu4oQB4neob8_MXs=.fd700eef-954d-4b5d-9b62-68afca0129d3@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
 <A7Fpb0bKWQfoAQsq5A4RM8jmWHAfu4oQB4neob8_MXs=.fd700eef-954d-4b5d-9b62-68afca0129d3@github.com>
Message-ID: <dtTzxJpprZEbAAjtW3lAZerpVKTnAPk5ArfK5B1cZs4=.d61779e7-2758-4f34-8e66-9ad52303ad2b@github.com>

On Wed, 28 May 2025 13:35:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1875:
>> 
>>> 1873: 
>>> 1874: oop java_lang_Thread::park_blocker(oop java_thread) {
>>> 1875:   return java_thread->obj_field_acquire(_park_blocker_offset);
>> 
>> Where is the releasing store that pairs with this load-acquire?
>
> Thread.parkBlocker is declared volatile but all access is done in opaque mode, so maybe this should MO_RELAXED?
> 
> In any case, I think we might have to drop the sampling of exclusiveOwnerThread for now. This can only be tested to see if it's the current thread, and only after a volatile-state of the state.

made access MO_RELAXED

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113109398

From amenkov at openjdk.org  Thu May 29 03:41:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:41:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <SsYnVpNyJ3gEN4zUep1HsiOf3cxnjgfQBY-ADUf93qc=.2ce52f00-f2c5-4709-a34c-bde5b0c12815@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <f13aDzfDaCxfCb-aAvpjukXhaEsR2DifVLomOWpsF8o=.cb2796fc-321f-4c2b-b8f9-99f962eddb39@github.com>
 <SsYnVpNyJ3gEN4zUep1HsiOf3cxnjgfQBY-ADUf93qc=.2ce52f00-f2c5-4709-a34c-bde5b0c12815@github.com>
Message-ID: <sra8AKO31wwGci2YH6yJYRdyu-iOYW85qfCZ0YH5tWo=.2d9ff28c-3cfc-455a-81dd-6bbdba651f18@github.com>

On Wed, 28 May 2025 19:36:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 2968:
>> 
>>> 2966:   oop snapshot = VMThreadSnapshot::get_thread_snapshot(jthread, THREAD);
>>> 2967:   return JNIHandles::make_local(THREAD, snapshot);
>>> 2968: #elif
>> 
>> Q: should it be `#else` instead of `#elif`?
>
> right. this breaks minimal build

Fixed

>> src/hotspot/share/services/threadService.cpp line 1317:
>> 
>>> 1315:         const ContinuationEntry* ce = _thread->vthread_continuation();
>>> 1316:         if (ce == nullptr || ce->cont_oop(_thread) != java_lang_VirtualThread::continuation(_java_thread())) {
>>> 1317:           // TODO: handle
>> 
>> Q: What `TODO` is expected here?
>
> actually it's unreachable. can be dropped

dropped the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113110875
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113108714

From amenkov at openjdk.org  Thu May 29 03:41:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:41:54 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
Message-ID: <hZ2sf43gQSRkFATfrZuC7dPfkW_DwfwGaD2tVDH3HDw=.886e3e62-93a6-4898-9912-9fd421495501@github.com>

On Wed, 28 May 2025 03:51:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1180:
> 
>> 1178:   GrowableArray<OwnedLock>* _locks;
>> 1179:   Blocker _blocker;
>> 1180:   OopHandle _blocker_owner;
> 
> Nit: Some short comments explaining the fields would be nice to have, at least for `_depth`, `_retry_handshake`, `_locks`, `_blocker` and `_blocker_owner`.

after offline discussion agreed that in most cases additional explanations are not required

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113108079

From amenkov at openjdk.org  Thu May 29 03:41:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:41:58 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <GzQcbyzD7iy44JEXPD8HKldR9R-Xe28_XuyDU3re7l8=.d15c7345-242a-4fe6-b8cd-9b5483106c3f@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
 <GzQcbyzD7iy44JEXPD8HKldR9R-Xe28_XuyDU3re7l8=.d15c7345-242a-4fe6-b8cd-9b5483106c3f@github.com>
Message-ID: <aWW6QnkrFnybYm1B-lxkQuSf6n8qn4rN2mNj3KWk-LQ=.1c663dfb-cd10-4d00-9f24-ad4c16297b3e@github.com>

On Wed, 28 May 2025 18:31:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/threadService.cpp line 1203:
>> 
>>> 1201:   }
>>> 1202: 
>>> 1203:   bool read_reset_retry() {
>> 
>> What does the `read` mean in the name?
>
> read and then reset the `retry` value (return old value)

removed "retry" logic

>> src/hotspot/share/services/threadService.cpp line 1206:
>> 
>>> 1204:     bool ret = _retry_handshake;
>>> 1205:     // If we re-execute the handshake this method need to return false
>>> 1206:     // when the handshake cannot be performed. (E.g. thread terminating)
>> 
>> Unclear what the comment means. The "retry" logic needs to be clearly explained somewhere.
>
> The logic comes from `java_lang_Thread::async_get_stack_trace()` (implementation of `java.lang.Thread.getStackTrace()`) I don't see why the handshake needs to be executed on JavaThread.

dropped "retry" logic

>> src/hotspot/share/services/threadService.cpp line 1531:
>> 
>>> 1529:   if (ste_klass->should_be_initialized()) {
>>> 1530:     ste_klass->initialize(CHECK_NULL);
>>> 1531:   }
>> 
>> Is this actually necessary? Doesn't this klass always get initialized as part of VM initialization?
>
> I suppose it's not necessary, just for safety

removed

>> src/hotspot/share/services/threadService.cpp line 1560:
>> 
>>> 1558:   // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace)
>>> 1559:   // to properly initialize STE.
>>> 1560:   {
>> 
>> Why the additional block scope?
>
> not needed anymore

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113111153
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113109960
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113110414
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113110713

From amenkov at openjdk.org  Thu May 29 03:41:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 03:41:56 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
Message-ID: <3_VJJ8qEsLUtnAczCZIrNLYPf2hTz556qTYqnA9vHsg=.f91d02c4-534d-4388-8b8c-cdbcea6bb046@github.com>

On Wed, 28 May 2025 07:09:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1189:
> 
>> 1187:     _thread_status(), _name(nullptr),
>> 1188:     _locks(nullptr), _blocker(), _blocker_owner(nullptr) { }
>> 1189:   virtual ~GetThreadSnapshotClosure() {
> 
> Suggestion:
> 
>     _locks(nullptr), _blocker(), _blocker_owner(nullptr) { 
>   }
>     
>   virtual ~GetThreadSnapshotClosure() {

Fixed

> src/hotspot/share/services/threadService.cpp line 1434:
> 
>> 1432:   static Handle allocate(InstanceKlass* klass, TRAPS) {
>> 1433:     init(klass, CHECK_NH);
>> 1434:     return klass->allocate_instance_handle(CHECK_NH);
> 
> Suggestion:
> 
>     return klass->allocate_instance_handle(CHECK_NH);
> 
> Suggestion:
> 
>     Handle h_k = klass->allocate_instance_handle(CHECK_NH);
>     return h_k;
> 
> You can't use `CHECK` on a `return` statement.

Thanks, fixed

> src/hotspot/share/services/threadService.cpp line 1528:
> 
>> 1526:   // StackTrace
>> 1527:   InstanceKlass* ste_klass = vmClasses::StackTraceElement_klass();
>> 1528:   assert(ste_klass != nullptr, "must be loaded in 1.4+");
> 
> Suggestion:
> 
>   assert(ste_klass != nullptr, "must be loaded");
> 
> The 1.4+ is not relevant these days

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113109592
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113110231
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113110556

From dholmes at openjdk.org  Thu May 29 05:55:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 May 2025 05:55:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <dApBOWgC1qg8WAw1rsGcuSS2XyrEjQAG8VSsbWjqblM=.4d93c1ef-11b1-4df3-9c6a-3567b0f8103d@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
 <7I-QS9aIISJbsTz7s9wT1I8EhWbsgxcM_l_CKqFnM2M=.2cf0303f-2b0e-406b-9fba-ac75a20bce59@github.com>
 <dApBOWgC1qg8WAw1rsGcuSS2XyrEjQAG8VSsbWjqblM=.4d93c1ef-11b1-4df3-9c6a-3567b0f8103d@github.com>
Message-ID: <QLrYOV_DMSKoi6kMUrPBnseSOVVGcd2LmbmSnCxCBm8=.41a92a36-9ffa-47d1-88a5-0dfc5cdb4a53@github.com>

On Wed, 28 May 2025 18:16:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> It's used by VMThreadSnapshot::get_thread_snapshot. The transition disabling support is currently in the jvmti code. I think this is the first usage in a handshake op that isn't supporting a JVMTI function. Maybe in the future this could be separated.
>
>> Why this change?
> To be more clear about the change:
> We need JvmtiVTMSTransitionDisabler for virtual threads only, for platform threads handshake is enough. And currently for platform threads JvmtiVTMSTransitionDisabler disables all mount/unmount transitions (and I'd prefer to avoid this).
> So we cannot create JvmtiVTMSTransitionDisabler on a stack (this is standard use scenario), but need to create it conditionally by `new`/`delete`

So `JvmtiVTMSTransitionDisabler` is no longer a RAII helper type? That sounds a backward step in usability.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113258435

From dholmes at openjdk.org  Thu May 29 06:01:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 May 2025 06:01:02 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
Message-ID: <bbVxJzJzSykcrC9MFRwLGnILXCppXT2NliNCfoe_QzQ=.cef36fd2-0266-4ed7-8c71-0c034b32c596@github.com>

On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - removed retry_handshake logic
>  - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>  - cleanup
>  - renamed java_thread, thread_h
>  - fixed minimal and zero

src/hotspot/share/services/threadService.cpp line 1145:

> 1143:     int _depth;
> 1144:     Type _type;
> 1145:     // synchronization object (when type == LOCKED) ot its klass (type == ELIMINATED)

Suggestion:

    // synchronization object (when type == LOCKED) or its klass (type == ELIMINATED)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113263697

From alanb at openjdk.org  Thu May 29 07:22:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 07:22:56 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
Message-ID: <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>

On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - removed retry_handshake logic
>  - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>  - cleanup
>  - renamed java_thread, thread_h
>  - fixed minimal and zero

src/hotspot/share/services/threadService.cpp line 1296:

> 1294:     }
> 1295: 
> 1296:     bool walk_cont = (_java_thread != nullptr) && (_java_thread->vthread_continuation() != nullptr);

Can you double check this? It looks like the refactor has changed something here and this will now walk the continuation when taking a snapshot of a carrier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113371681

From amenkov at openjdk.org  Thu May 29 07:58:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 07:58:41 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v5]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/services/threadService.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/ff334ab6..025d9f27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/25425

From amenkov at openjdk.org  Thu May 29 08:03:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 08:03:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
Message-ID: <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>

On Thu, 29 May 2025 07:19:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - removed retry_handshake logic
>>  - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>>  - cleanup
>>  - renamed java_thread, thread_h
>>  - fixed minimal and zero
>
> src/hotspot/share/services/threadService.cpp line 1296:
> 
>> 1294:     }
>> 1295: 
>> 1296:     bool walk_cont = (_java_thread != nullptr) && (_java_thread->vthread_continuation() != nullptr);
> 
> Can you double check this? It looks like the refactor has changed something here and this will now walk the continuation when taking a snapshot of a carrier.

The logic is the same as before.
The problem is the variable name. it's `bool vthread_carrier` argument of vframeStream ctor. Will change the name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113432073

From sspitsyn at openjdk.org  Thu May 29 08:09:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 08:09:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
Message-ID: <SfAccV1MsC6c3Vdia0bInrOX2y32J179z07lCkmITeY=.52824c81-60ee-40d0-a8ac-a37a5e53c682@github.com>

On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - removed retry_handshake logic
>  - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>  - cleanup
>  - renamed java_thread, thread_h
>  - fixed minimal and zero

src/hotspot/share/services/threadService.cpp line 1143:

> 1141:     };
> 1142: 
> 1143:     int _depth;

Nit: I'm thinking if `_depth` can be renamed to `_frame_depth`.
Then it will be self-explained, so no comment is needed.

src/hotspot/share/services/threadService.cpp line 1178:

> 1176:   GrowableArray<int>* _bcis;
> 1177:   JavaThreadStatus _thread_status;
> 1178:   OopHandle _name;

Nit: Maybe rename is to `_thread_name` or `_tname`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113427639
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113430612

From sspitsyn at openjdk.org  Thu May 29 08:09:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 08:09:55 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <dVgt_WEsgJO88b2BifHkdPjOOzvvWwPXGK6yqhS8Hm8=.c421168a-b621-481f-b6e7-90ab15a52edf@github.com>
Message-ID: <-jdIaXA8D91dmn3wUgK-wAOI4DbvVqNK0IRb0r0axsI=.89a3ada6-bc6e-4f47-8225-4c8f1ece5b04@github.com>

On Wed, 28 May 2025 07:35:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1160:
> 
>> 1158: 
>> 1159:     Type _type;
>> 1160:     OopHandle _obj;
> 
> Nit: Short comments for `_depth` and `_obj` fields (lines: 1142, 1144, 1160) would be nice to have.

Nit: A comment, similar to the one at line 1145 would be nice to have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113425437

From amenkov at openjdk.org  Thu May 29 08:14:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 08:14:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v2]
In-Reply-To: <QLrYOV_DMSKoi6kMUrPBnseSOVVGcd2LmbmSnCxCBm8=.41a92a36-9ffa-47d1-88a5-0dfc5cdb4a53@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <SkdN2H5GQ3dtfXTauWBDMowEaUNYLto8LSc_QSNLroE=.25726d65-cf5c-4daf-95a1-696c50466078@github.com>
 <w6zdZ-I-fKV0ivmAOGeGGTGqj51ocqknPuFKKrA4Ozs=.87947f9f-1924-4fae-b20f-00d3c496a6f1@github.com>
 <7I-QS9aIISJbsTz7s9wT1I8EhWbsgxcM_l_CKqFnM2M=.2cf0303f-2b0e-406b-9fba-ac75a20bce59@github.com>
 <dApBOWgC1qg8WAw1rsGcuSS2XyrEjQAG8VSsbWjqblM=.4d93c1ef-11b1-4df3-9c6a-3567b0f8103d@github.com>
 <QLrYOV_DMSKoi6kMUrPBnseSOVVGcd2LmbmSnCxCBm8=.41a92a36-9ffa-47d1-88a5-0dfc5cdb4a53@github.com>
Message-ID: <PGNFmsuUyGrrhvrBUcxDTq41zCsa_FiKybURyqtnV_0=.a487e636-2074-43a8-a795-778a8f65c66f@github.com>

On Thu, 29 May 2025 05:52:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Why this change?
>> To be more clear about the change:
>> We need JvmtiVTMSTransitionDisabler for virtual threads only, for platform threads handshake is enough. And currently for platform threads JvmtiVTMSTransitionDisabler disables all mount/unmount transitions (and I'd prefer to avoid this).
>> So we can create JvmtiVTMSTransitionDisabler on stack (this is standard use scenario), but need to create it conditionally by `new`/`delete`
>
> So `JvmtiVTMSTransitionDisabler` is no longer a RAII helper type? That sounds a backward step in usability.

No. Sorry, my comment had a error (I updated it). This change just allow `JvmtiVTMSTransitionDisabler` to be heap allocated.
Class `TransitionDisabler` in `VMThreadSnapshot::get_thread_snapshot` (line 1444 in threadService.cpp) is kind of smart pointer to `JvmtiVTMSTransitionDisabler`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113448661

From alanb at openjdk.org  Thu May 29 08:14:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 08:14:55 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
 <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>
Message-ID: <AiQ-U9OgR2_jqHzhEWdYNfjNtnUOHbRaiNFgZMR3kKA=.0688c114-7ff3-46c0-8252-ab5ac2a30867@github.com>

On Thu, 29 May 2025 08:01:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/threadService.cpp line 1296:
>> 
>>> 1294:     }
>>> 1295: 
>>> 1296:     bool walk_cont = (_java_thread != nullptr) && (_java_thread->vthread_continuation() != nullptr);
>> 
>> Can you double check this? It looks like the refactor has changed something here and this will now walk the continuation when taking a snapshot of a carrier.
>
> The logic is the same as before.
> The problem is the variable name. it's `bool vthread_carrier` argument of vframeStream ctor. Will change the name

Something isn't right here. Are you sure walk_cont is correctly for the mounted virtual thread case? There are several tests failing now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113448843

From sspitsyn at openjdk.org  Thu May 29 08:30:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 08:30:59 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v5]
In-Reply-To: <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>
Message-ID: <sRwhz8E7V29FbmIonZc2-FvNUT_2cK5pmo5sQQBmVhU=.26970c9a-1fe5-4188-b21c-c015bf4ff880@github.com>

On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/services/threadService.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Alex, thank you for the updates! It is getting better. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2918694993

From sspitsyn at openjdk.org  Thu May 29 08:30:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 08:30:59 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <AiQ-U9OgR2_jqHzhEWdYNfjNtnUOHbRaiNFgZMR3kKA=.0688c114-7ff3-46c0-8252-ab5ac2a30867@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
 <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>
 <AiQ-U9OgR2_jqHzhEWdYNfjNtnUOHbRaiNFgZMR3kKA=.0688c114-7ff3-46c0-8252-ab5ac2a30867@github.com>
Message-ID: <3iOycQ844yz6zkoNYMo0nGC4OF_UCU-nFP6e6qmApao=.010795be-7f36-4664-b64e-20cadaa7906e@github.com>

On Thu, 29 May 2025 08:12:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The logic is the same as before.
>> The problem is the variable name. it's `bool vthread_carrier` argument of vframeStream ctor. Will change the name
>
> Something isn't right here. Are you sure walk_cont is correctly for the mounted virtual thread case? There are several tests failing now.

Let's check the logic before and now:
 - before:
   `walk_cont = _java_thread != nullptr && !is_virtual && _thread->vthread_continuation() != nullptr`
 - now:
   `walk_cont = _java_thread != nullptr && _thread->vthread_continuation() != nullptr`
 
 Alan's concern is that the check for  `!is_virtual` is missed now.
 I'm not sure yet if it created a problem but the logic is a bit different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113469974

From alanb at openjdk.org  Thu May 29 08:55:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 08:55:55 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <3iOycQ844yz6zkoNYMo0nGC4OF_UCU-nFP6e6qmApao=.010795be-7f36-4664-b64e-20cadaa7906e@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
 <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>
 <AiQ-U9OgR2_jqHzhEWdYNfjNtnUOHbRaiNFgZMR3kKA=.0688c114-7ff3-46c0-8252-ab5ac2a30867@github.com>
 <3iOycQ844yz6zkoNYMo0nGC4OF_UCU-nFP6e6qmApao=.010795be-7f36-4664-b64e-20cadaa7906e@github.com>
Message-ID: <8smrI3bSOOD8muSZxYw0_Zgu4eRfzjCuS2jp1E0-bx0=.5fa1239f-2e64-4dd5-8546-5c4bc0631868@github.com>

On Thu, 29 May 2025 08:26:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Something isn't right here. Are you sure walk_cont is correctly for the mounted virtual thread case? There are several tests failing now.
>
> Let's check the logic before and now:
>  - before:
>    `walk_cont = _java_thread != nullptr && !is_virtual && _thread->vthread_continuation() != nullptr`
>  - now:
>    `walk_cont = _java_thread != nullptr && _thread->vthread_continuation() != nullptr`
>  
>  Alan's concern is that the check for  `!is_virtual` is missed now.
>  I'm not sure yet if it created a problem but the logic is a bit different.

If renamed to bool vthread_carrier then it will be clearer to see that the logic isn't right. It should only be true when !is_virtual and there is a mounted virtual thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2113518924

From aph at openjdk.org  Thu May 29 09:37:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 May 2025 09:37:54 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v4]
In-Reply-To: <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <ZolWi-wMKO1B6lynlJ1MzBQSHEWeciFL4ULcNFi_GNU=.ace9bd9a-4f22-405e-bbb8-4d6f8cd4203b@github.com>
Message-ID: <F1dBLQnYUgXiQHUETwC3DGuhydCDn_giyQNpzEORwsQ=.bb6a053a-acae-4b84-b615-ceb3515933b7@github.com>

On Fri, 9 May 2025 22:34:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move other tier 4,5, etc tests to not use ClassReader
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Use classfile api instead of javac setting version
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - 8356548: Avoid using ASM to parse latest class files in tests

test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java line 79:

> 77:                     }
> 78: 
> 79:                     /* a code generate looks like

Suggestion:

                    /* the code generated looks like

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2113583647

From sspitsyn at openjdk.org  Thu May 29 10:02:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 10:02:52 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName()
In-Reply-To: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
Message-ID: <uCmp3Hk2Av5_uGUBPILo4YFPEfGsQs14brwKbJZdhk8=.5c657bb2-bba5-4699-a891-0c9551615a95@github.com>

On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
> 
> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
> 
> Tested nsk/jdi test locally. Will do more thorough ci testing.

Looks good. Nice refactoring.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25337#pullrequestreview-2877741782

From alanb at openjdk.org  Thu May 29 10:15:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 10:15:20 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

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

 - Temp fixed until fixed in pull/25425
 - Sync up from loom repo, includes review comments
 - Merge branch 'pull/25425' into JDK-8356870
 - Merge branch 'pull/25425' into JDK-8356870
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25429/files
  - new: https://git.openjdk.org/jdk/pull/25429/files/52bb3de7..04f559fb

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

  Stats: 30027 lines in 609 files changed: 20669 ins; 6244 del; 3114 mod
  Patch: https://git.openjdk.org/jdk/pull/25429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429

PR: https://git.openjdk.org/jdk/pull/25429

From alanb at openjdk.org  Thu May 29 10:15:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 10:15:21 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v2]
In-Reply-To: <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <d_r7m9tIFnytfvtarD6YrO1Qw1TLSTK8trs6byqxYS0=.b906b34f-bfee-4a08-9e07-07268a97bf67@github.com>
Message-ID: <QT2eOEUnwKrTCCW3T3XEQ1W8K-Jb_3yEbFw-xDMiKq8=.c25a4a1c-6fcd-47a3-94b7-ab812070b458@github.com>

On Sun, 25 May 2025 06:21:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Sync'ed up to the pull/25425.

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

PR Comment: https://git.openjdk.org/jdk/pull/25429#issuecomment-2918939334

From kevin.walls at oracle.com  Thu May 29 10:21:16 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 29 May 2025 10:21:16 +0000
Subject: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
In-Reply-To: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
Message-ID: <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi --

Just to be clear, is this an actual persistent leak that we can observe, or is it that we could close earlier with try-with-resources?
I'm not seeing a leak when calling a line like this over and over in a tight loop:
  final var cmdline = Files.lines(path).findFirst();

Thanks!
Kevin



________________________________
From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Philippe Marschall <kustos at gmx.net>
Sent: Saturday, May 24, 2025 8:26 PM
To: serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Subject: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles

Hello

I believe sun.tools.attach.VirtualMachineImpl#checkCatchesAndSendQuitTo
on Linux leaks file handles after JDK-8327114 [1].

The issue is the line 361 [2]

final var cmdline = Files.lines(procPid.resolve("cmdline")).findFirst();

Because the Stream is not closed the file handle is not closed as well.

Compare this to ProcessHelper#getCommandLine which uses the correct idiom.

try (Stream<String> lines =
     Files.lines(Paths.get("/proc/" + pid + "/cmdline"))) {
     return lines.findFirst().orElse(null);
}

The fix is easy, rewrite the code like so:

final Optional<String> cmdline;
try (var lines = Files.lines(procPid.resolve("cmdline"))) {
     cmdline = lines.findFirst();
}

If somebody opens a JIRA bug I can work on a PR.

  [1] https://bugs.openjdk.org/browse/JDK-8327114
  [2]
https://github.com/openjdk/jdk/blob/master/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L361
  [3]
https://github.com/openjdk/jdk/blob/master/src/jdk.jcmd/linux/classes/sun/tools/common/ProcessHelper.java#L117

Regards
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/f6b75092/attachment.htm>

From coleenp at openjdk.org  Thu May 29 11:42:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 May 2025 11:42:57 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <YwRARMZsI1v1_pp-fiPhXQcCMGoCYckkPBnjCcPrRuE=.0033d123-0533-41d2-b02f-f108bd22bdb3@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <XsSMHjFwdUj4jxXcuEFj1ryPAe3H7vZWn-dUIX9b9s4=.9b1ea875-491e-42bf-97f3-e99773b1c0f1@github.com>
 <dxRhh7QO7C9VHnpd9mU0YRUnDgT80BrSIxLiJYDBIIE=.98bd093b-de12-4438-bb73-579dfcd02745@github.com>
 <YwRARMZsI1v1_pp-fiPhXQcCMGoCYckkPBnjCcPrRuE=.0033d123-0533-41d2-b02f-f108bd22bdb3@github.com>
Message-ID: <R-R039GksvUhVUgIIc94AV2tzQq8ZxuKcCh3Ry99O3M=.c9722c97-794b-4211-90ac-8ece79e63318@github.com>

On Tue, 20 May 2025 20:24:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The references are still correct, as we haven't changed the struct layout. We're also not planning on doing so. I don't think that there is a bug here.
>
> Ok. It's just unusual to see constants like these that are needed by SA but serve no purpose in hotspot.

It does seem like you want to mirror these constants from the vmStructs side like it was rather than defining them here in the SA.  I see why you did this but maybe you can add the constants to BSMAttributeEntry and declare them constants using declare_constant(BSMAttributeEntry::_indy...).
In case you change them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2113771428

From coleenp at openjdk.org  Thu May 29 11:42:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 May 2025 11:42:57 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
Message-ID: <1hRbdQaSLg_kjJe7Nhj2do5AFBTcMcAOkvDTOofeXaA=.2c2c1cd3-350d-47fa-b0d0-05308ae1f4b6@github.com>

On Thu, 22 May 2025 17:55:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lois's comments

I think this looks like a nice improvement but I thought operands was going to turn into two arrays?  Also there's probably a better name than 'operands' maybe bsm_operands?

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

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2877989027

From lmesnik at openjdk.org  Thu May 29 14:49:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 29 May 2025 14:49:50 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName()
In-Reply-To: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
Message-ID: <9Vm1RnnGraCsm3Trfa8ySVxl24dWkc5h8b8Kh9T5P80=.7fea7220-76f5-495f-9a86-40d948e4856d@github.com>

On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
> 
> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
> 
> Tested nsk/jdi test locally. Will do more thorough ci testing.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25337#pullrequestreview-2878567516

From larry.cable at oracle.com  Thu May 29 14:56:07 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 29 May 2025 07:56:07 -0700
Subject: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
In-Reply-To: <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <7850942b-5d32-4668-8b27-85479b678bee@oracle.com>

probably makes sense to fix regardless... my bad

On 5/29/25 3:21 AM, Kevin Walls wrote:
> Hi --
>
> Just to be clear, is this an actual persistent leak that we can 
> observe, or is it that we could close earlier with try-with-resources?
> I'm not seeing a leak when calling a line like this over and over in a 
> tight loop:
> ? final var cmdline = Files.lines(path).findFirst();
>
> Thanks!
> Kevin
>
>
>
> ------------------------------------------------------------------------
> *From:* serviceability-dev <serviceability-dev-retn at openjdk.org> on 
> behalf of Philippe Marschall <kustos at gmx.net>
> *Sent:* Saturday, May 24, 2025 8:26 PM
> *To:* serviceability-dev at openjdk.java.net 
> <serviceability-dev at openjdk.java.net>
> *Subject:* VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file 
> handles
> Hello
>
> I believe sun.tools.attach.VirtualMachineImpl#checkCatchesAndSendQuitTo
> on Linux leaks file handles after JDK-8327114 [1].
>
> The issue is the line 361 [2]
>
> final var cmdline = Files.lines(procPid.resolve("cmdline")).findFirst();
>
> Because the Stream is not closed the file handle is not closed as well.
>
> Compare this to ProcessHelper#getCommandLine which uses the correct idiom.
>
> try (Stream<String> lines =
> ???? Files.lines(Paths.get("/proc/" + pid + "/cmdline"))) {
> ???? return lines.findFirst().orElse(null);
> }
>
> The fix is easy, rewrite the code like so:
>
> final Optional<String> cmdline;
> try (var lines = Files.lines(procPid.resolve("cmdline"))) {
> ???? cmdline = lines.findFirst();
> }
>
> If somebody opens a JIRA bug I can work on a PR.
>
> ? [1] https://bugs.openjdk.org/browse/JDK-8327114
> ? [2]
> https://github.com/openjdk/jdk/blob/master/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L361
> ? [3]
> https://github.com/openjdk/jdk/blob/master/src/jdk.jcmd/linux/classes/sun/tools/common/ProcessHelper.java#L117
>
> Regards
> Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/d1e764a4/attachment-0001.htm>

From shade at openjdk.org  Thu May 29 15:10:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 May 2025 15:10:01 GMT
Subject: Integrated: 8357999: SA: FileMapInfo.metadataTypeArray initialization
 issue after JDK-8355003
In-Reply-To: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
References: <_Phg54iSIDv37FdElr9Z7MT7nZg64K037DPPMsd5Qmc=.aad942ca-ba9e-4539-b436-8de34f06c54b@github.com>
Message-ID: <KXQMaCXBOgNbBMAXvRpTMHU6Jb4KdVTg0KZGhJdCq7M=.b29ad921-48da-4f01-9146-d8c7b353feea@github.com>

On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports an issue since [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration: duplicate index in `metadataTypeArray` initialization code. Looks like a simple typo, this PR fixes it. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/sa`

This pull request has now been integrated.

Changeset: d8a78302
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8a783020d247d2c01834db14b44d239ad1f2bf4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357999: SA: FileMapInfo.metadataTypeArray initialization issue after JDK-8355003

Reviewed-by: ayang, iklam, kvn, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25507

From jbechberger at openjdk.org  Thu May 29 16:26:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 29 May 2025 16:26:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v23]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <qZnVk7hAyH7Lq9NmXV4oPPwLSvkZtYFE70nxKTe8olg=.49c2f926-58c8-4ddd-bfc9-beb394090da1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:

 - Fix merge
 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix merge mistake
 - Replace views with cpu-time-statistics view
 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix builds on non Linux platforms
 - Tiny fixes
 - Tiny fixes
 - Remove assertion
 - Remove mistake
 - ... and 83 more: https://git.openjdk.org/jdk/compare/79aff26c...adcbec51

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=22
  Stats: 2303 lines in 44 files changed: 2157 ins; 130 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From kustos at gmx.net  Thu May 29 16:47:07 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Thu, 29 May 2025 18:47:07 +0200
Subject: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
In-Reply-To: <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>




On 29.05.25 12:21, Kevin Walls wrote:
> Hi --
> 
> Just to be clear, is this an actual persistent leak that we can observe, or is it that we could close earlier with try-with-resources?
> I'm not seeing a leak when calling a line like this over and over in a tight loop:
>    final var cmdline = Files.lines(path).findFirst();

I believe it is persistent until the Cleaner of FileChannel closes it. 
The #line Javadoc [1] mentions the need to close

 > This method must be used within a try-with-resources statement or
 > similar control structure to ensure that the stream's open file is
 > closed promptly after the stream's operations have completed.

The Stream class Javadoc [2] explicitly mentions #lines as well

 > Generally, only streams whose source is an IO channel, such as those
 > returned by Files.lines(Path), will require closing. If a stream does
 > require closing, it must be opened as a resource within a
 > try-with-resources statement or similar control structure to ensure
 > that it is closed promptly after its operations have completed.

If I run something like the code below I get 
java.nio.file.FileSystemException: marker: Too many open files. You can 
also lower the number, set a breakpoint at System.out.println and check 
/proc/<pid>/fd


Path marker = Path.of("marker");
if (!Files.exists(marker)) {
   Files.writeString(marker, "line1");
}
// usually over the max fd limit
int fileCount = 100_000;
// prevent streams from being garbage collected and cleaner to run and 
close fd
List<Stream<?>> streams = new ArrayList<>(fileCount);
for (int i = 0; i < fileCount; i++) {
   Stream<String> stream = Files.lines(marker);
   streams.add(stream);
   Optional<String> firstLine = stream.findFirst();
   if (firstLine.isPresent()) {
     if (firstLine.get().hashCode() == 42) {
       System.out.println('x');
     }
   }
}
System.out.println(streams.hashCode());

  [1] 
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#lines(java.nio.file.Path)
  [2] 
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html

Regards
Philippe

From cjplummer at openjdk.org  Thu May 29 16:57:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 29 May 2025 16:57:55 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
Message-ID: <JS5g-5LgtafzTPV5LqyHToc61jpAO3gGrjSXLtruJrg=.bada29d6-1613-43f4-b938-a5f1ab2f3c35@github.com>

On Wed, 14 May 2025 18:54:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.

Sill looking for reviewers. This is a very simple PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25236#issuecomment-2920003298

From cjplummer at openjdk.org  Thu May 29 17:02:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 29 May 2025 17:02:09 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName() [v2]
In-Reply-To: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
Message-ID: <8F0yD8g0cUFrra5n4SjtfRaKQrlvnThSfvVPneltVF8=.012eb29c-c82c-4d38-91d7-37a24eaf55c4@github.com>

> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
> 
> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
> 
> Tested nsk/jdi test locally. Will do more thorough ci testing.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  minor whitespace fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25337/files
  - new: https://git.openjdk.org/jdk/pull/25337/files/1ed374f5..d94c056d

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25337/head:pull/25337

PR: https://git.openjdk.org/jdk/pull/25337

From kevinw at openjdk.org  Thu May 29 17:59:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 29 May 2025 17:59:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v5]
In-Reply-To: <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>
Message-ID: <zHRrYNr0yz8Uub2fnuggIgMAHaAiL4_NeIZHbDXeY-g=.bbc40917-573a-46b7-b633-9b4cf24e356a@github.com>

On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/services/threadService.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/share/services/threadService.hpp line 634:

> 632: };
> 633: 
> 634: 

I'm finding the class name VMThreadSnapshot confusing, as it's used to create a snapshot of any thread in the VM, not of the "VMThread".  This space is crowded, we have a class ThreadSnapshot here already.

VMThreadSnapshot is an AllStatic class with one method for creating snapshots... How about ThreadSnapshotFactory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2114473010

From kevin.walls at oracle.com  Thu May 29 18:05:46 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 29 May 2025 18:05:46 +0000
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
Message-ID: <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>

OK thanks Philippe, and Larry -

I can't provoke a problem as it stands but yes it would be good to take the recommendation of the API Note, that should keep us efficient. 8-)

I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088

Thanks!
Kevin
________________________________
From: Philippe Marschall <kustos at gmx.net>
Sent: Thursday, May 29, 2025 5:47 PM
To: Kevin Walls <kevin.walls at oracle.com>; serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles




On 29.05.25 12:21, Kevin Walls wrote:
> Hi --
>
> Just to be clear, is this an actual persistent leak that we can observe, or is it that we could close earlier with try-with-resources?
> I'm not seeing a leak when calling a line like this over and over in a tight loop:
>    final var cmdline = Files.lines(path).findFirst();

I believe it is persistent until the Cleaner of FileChannel closes it.
The #line Javadoc [1] mentions the need to close

 > This method must be used within a try-with-resources statement or
 > similar control structure to ensure that the stream's open file is
 > closed promptly after the stream's operations have completed.

The Stream class Javadoc [2] explicitly mentions #lines as well

 > Generally, only streams whose source is an IO channel, such as those
 > returned by Files.lines(Path), will require closing. If a stream does
 > require closing, it must be opened as a resource within a
 > try-with-resources statement or similar control structure to ensure
 > that it is closed promptly after its operations have completed.

If I run something like the code below I get
java.nio.file.FileSystemException: marker: Too many open files. You can
also lower the number, set a breakpoint at System.out.println and check
/proc/<pid>/fd


Path marker = Path.of("marker");
if (!Files.exists(marker)) {
   Files.writeString(marker, "line1");
}
// usually over the max fd limit
int fileCount = 100_000;
// prevent streams from being garbage collected and cleaner to run and
close fd
List<Stream<?>> streams = new ArrayList<>(fileCount);
for (int i = 0; i < fileCount; i++) {
   Stream<String> stream = Files.lines(marker);
   streams.add(stream);
   Optional<String> firstLine = stream.findFirst();
   if (firstLine.isPresent()) {
     if (firstLine.get().hashCode() == 42) {
       System.out.println('x');
     }
   }
}
System.out.println(streams.hashCode());

  [1]
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#lines(java.nio.file.Path)
  [2]
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html

Regards
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/479bdfef/attachment-0001.htm>

From larry.cable at oracle.com  Thu May 29 18:08:36 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 29 May 2025 11:08:36 -0700
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <f345bfb7-4b18-40eb-b4b0-52b02a4dc8a4@oracle.com>

actually so did I ...


On 5/29/25 11:05 AM, Kevin Walls wrote:
> OK thanks Philippe, and Larry -
>
> I can't provoke a problem as it stands but yes it would be good to 
> take the recommendation of the API Note, that should keep us 
> efficient. 8-)
>
> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>
> Thanks!
> Kevin
> ------------------------------------------------------------------------
> *From:* Philippe Marschall <kustos at gmx.net>
> *Sent:* Thursday, May 29, 2025 5:47 PM
> *To:* Kevin Walls <kevin.walls at oracle.com>; 
> serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
> *Subject:* [External] : Re: 
> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>
>
>
> On 29.05.25 12:21, Kevin Walls wrote:
> > Hi --
> >
> > Just to be clear, is this an actual persistent leak that we can 
> observe, or is it that we could close earlier with try-with-resources?
> > I'm not seeing a leak when calling a line like this over and over in 
> a tight loop:
> >??? final var cmdline = Files.lines(path).findFirst();
>
> I believe it is persistent until the Cleaner of FileChannel closes it.
> The #line Javadoc [1] mentions the need to close
>
> ?> This method must be used within a try-with-resources statement or
> ?> similar control structure to ensure that the stream's open file is
> ?> closed promptly after the stream's operations have completed.
>
> The Stream class Javadoc [2] explicitly mentions #lines as well
>
> ?> Generally, only streams whose source is an IO channel, such as those
> ?> returned by Files.lines(Path), will require closing. If a stream does
> ?> require closing, it must be opened as a resource within a
> ?> try-with-resources statement or similar control structure to ensure
> ?> that it is closed promptly after its operations have completed.
>
> If I run something like the code below I get
> java.nio.file.FileSystemException: marker: Too many open files. You can
> also lower the number, set a breakpoint at System.out.println and check
> /proc/<pid>/fd
>
>
> Path marker = Path.of("marker");
> if (!Files.exists(marker)) {
> ?? Files.writeString(marker, "line1");
> }
> // usually over the max fd limit
> int fileCount = 100_000;
> // prevent streams from being garbage collected and cleaner to run and
> close fd
> List<Stream<?>> streams = new ArrayList<>(fileCount);
> for (int i = 0; i < fileCount; i++) {
> ?? Stream<String> stream = Files.lines(marker);
> ?? streams.add(stream);
> ?? Optional<String> firstLine = stream.findFirst();
> ?? if (firstLine.isPresent()) {
> ???? if (firstLine.get().hashCode() == 42) {
> ?????? System.out.println('x');
> ???? }
> ?? }
> }
> System.out.println(streams.hashCode());
>
> ? [1]
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#lines(java.nio.file.Path) 
>
> ? [2]
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html 
>
>
> Regards
> Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/ce4f80d2/attachment.htm>

From lmesnik at openjdk.org  Thu May 29 18:13:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 29 May 2025 18:13:53 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
Message-ID: <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>

On Wed, 14 May 2025 18:54:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java line 83:

> 81:     private ReferenceType rType, rTypeEx;
> 82:     private String cmd;
> 83:     private volatile int counter1 = 0, counter2 = 0;

The volatile is not enough for increment. It might be not affect test if you check 0/non-0 only but still not a good way.
Better to use AtomicInteger or set/read variable only.

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

PR Review: https://git.openjdk.org/jdk/pull/25236#pullrequestreview-2879186245
PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114495149

From amenkov at openjdk.org  Thu May 29 18:15:38 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 18:15:38 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v6]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <Zok5Nlfpgtweiwj_DmCB4AUFxBCV5EDJJ5HeRHVacKU=.285ac712-7457-4397-a21c-885cc79da6ed@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/025d9f27..d1f463ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=04-05

  Stats: 20 lines in 3 files changed: 1 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From lmesnik at openjdk.org  Thu May 29 18:15:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 29 May 2025 18:15:55 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName() [v2]
In-Reply-To: <8F0yD8g0cUFrra5n4SjtfRaKQrlvnThSfvVPneltVF8=.012eb29c-c82c-4d38-91d7-37a24eaf55c4@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
 <8F0yD8g0cUFrra5n4SjtfRaKQrlvnThSfvVPneltVF8=.012eb29c-c82c-4d38-91d7-37a24eaf55c4@github.com>
Message-ID: <2lYs1-JfULih3tJaj35JwanyjsQmqSJ-_nH0PvmRcvw=.14915283-c11d-432e-9d27-1fe77913ca30@github.com>

On Thu, 29 May 2025 17:02:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
>> 
>> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
>> 
>> Tested nsk/jdi test locally. Will do more thorough ci testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor whitespace fix

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25337#pullrequestreview-2879191008

From amenkov at openjdk.org  Thu May 29 18:21:11 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 18:21:11 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v7]
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25425/files
  - new: https://git.openjdk.org/jdk/pull/25425/files/d1f463ba..2ed5fa85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/25425

From amenkov at openjdk.org  Thu May 29 18:21:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 18:21:12 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v5]
In-Reply-To: <zHRrYNr0yz8Uub2fnuggIgMAHaAiL4_NeIZHbDXeY-g=.bbc40917-573a-46b7-b633-9b4cf24e356a@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <KMSYeO4e9TI-W1JRiytLqOF0bCnQZy1IbXIkGacOw3w=.b70e66a6-9a76-44fb-a8f6-0320dda60bf2@github.com>
 <zHRrYNr0yz8Uub2fnuggIgMAHaAiL4_NeIZHbDXeY-g=.bbc40917-573a-46b7-b633-9b4cf24e356a@github.com>
Message-ID: <NM2t3TcjzbI89PJz2hH-PNnUDtwz41IQ5GVLonx_sBo=.bec25c7f-9da6-4821-b496-4f9e800a945a@github.com>

On Thu, 29 May 2025 17:57:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/services/threadService.cpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/services/threadService.hpp line 634:
> 
>> 632: };
>> 633: 
>> 634: 
> 
> I'm finding the class name VMThreadSnapshot confusing, as it's used to create a snapshot of any thread in the VM, not of the "VMThread".  This space is crowded, we have a class ThreadSnapshot here already.
> 
> VMThreadSnapshot is an AllStatic class with one method for creating snapshots... How about ThreadSnapshotFactory?

Renamed to ThreadSnapshotFactory

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2114496823

From amenkov at openjdk.org  Thu May 29 18:21:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 18:21:12 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <SfAccV1MsC6c3Vdia0bInrOX2y32J179z07lCkmITeY=.52824c81-60ee-40d0-a8ac-a37a5e53c682@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <SfAccV1MsC6c3Vdia0bInrOX2y32J179z07lCkmITeY=.52824c81-60ee-40d0-a8ac-a37a5e53c682@github.com>
Message-ID: <b3T5l92aqBUasfEv2rSz7jWQ2TlS9bYKozUQG4T_BhE=.85be72ad-307e-4d44-9c45-eef74a6053ba@github.com>

On Thu, 29 May 2025 07:57:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - removed retry_handshake logic
>>  - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>>  - cleanup
>>  - renamed java_thread, thread_h
>>  - fixed minimal and zero
>
> src/hotspot/share/services/threadService.cpp line 1143:
> 
>> 1141:     };
>> 1142: 
>> 1143:     int _depth;
> 
> Nit: I'm thinking if `_depth` can be renamed to `_frame_depth`.
> Then it will be self-explained, so no comment is needed.

done

> src/hotspot/share/services/threadService.cpp line 1178:
> 
>> 1176:   GrowableArray<int>* _bcis;
>> 1177:   JavaThreadStatus _thread_status;
>> 1178:   OopHandle _name;
> 
> Nit: Maybe rename is to `_thread_name` or `_tname`.

yes, forgot about it. done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2114492455
PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2114493602

From amenkov at openjdk.org  Thu May 29 18:21:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 18:21:12 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v4]
In-Reply-To: <8smrI3bSOOD8muSZxYw0_Zgu4eRfzjCuS2jp1E0-bx0=.5fa1239f-2e64-4dd5-8546-5c4bc0631868@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <aZh5h0w8gtfmY3NPaH9n_-qCThknN-5uYSqIFKWBu8M=.31ba9d5e-7bf7-4ef9-8759-d2ba2af5ffd7@github.com>
 <KnIbyjHG4CkjhOMo9U9czYnmUsuJqPORsWxRfG9t8Yo=.d66218be-dea5-46bb-8836-3afa48a2fe15@github.com>
 <YONabOSPeMBi7v6cYJsejbBUE9AbIkxGU2fWDNybmsY=.e4807809-88b2-4675-b72c-0d294e6d4d24@github.com>
 <AiQ-U9OgR2_jqHzhEWdYNfjNtnUOHbRaiNFgZMR3kKA=.0688c114-7ff3-46c0-8252-ab5ac2a30867@github.com>
 <3iOycQ844yz6zkoNYMo0nGC4OF_UCU-nFP6e6qmApao=.010795be-7f36-4664-b64e-20cadaa7906e@github.com>
 <8smrI3bSOOD8muSZxYw0_Zgu4eRfzjCuS2jp1E0-bx0=.5fa1239f-2e64-4dd5-8546-5c4bc0631868@github.com>
Message-ID: <VopFr55EMNobTWd_2n9GfzchHko1OPUzZzkHXPj-2OI=.218bff40-8568-40a1-bb51-a85ba0ecda0a@github.com>

On Thu, 29 May 2025 08:53:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Let's check the logic before and now:
>>  - before:
>>    `walk_cont = _java_thread != nullptr && !is_virtual && _thread->vthread_continuation() != nullptr`
>>  - now:
>>    `walk_cont = _java_thread != nullptr && _thread->vthread_continuation() != nullptr`
>>  
>>  Alan's concern is that the check for  `!is_virtual` is missed now.
>>  I'm not sure yet if it created a problem but the logic is a bit different.
>
> If renamed to bool vthread_carrier then it will be clearer to see that the logic isn't right now. It should only be true when !is_virtual and there is a mounted virtual thread.

Right, thanks for catching. Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25425#discussion_r2114496019

From sspitsyn at openjdk.org  Thu May 29 18:28:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 18:28:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v7]
In-Reply-To: <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
Message-ID: <TUik91CJTS2SNOaHYat_7tecF6LSTPqjIwoGMzk9QMg=.ceb966fb-1d95-4328-844f-daefe8f5645c@github.com>

On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Alex, thank you for the updates!
Looks good now.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25425#pullrequestreview-2879223457

From sspitsyn at openjdk.org  Thu May 29 18:36:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 May 2025 18:36:50 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <POlOwmM1kzLJUBBV-pE0SazmKvLVAE4vatJ7xrhUkpw=.e2a0a691-fa6c-4e03-94fd-e1591e741a10@github.com>

On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

PING: Still need this test update reviewed, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/25422#issuecomment-2920242845

From larry.cable at oracle.com  Thu May 29 18:51:15 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 29 May 2025 11:51:15 -0700
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>

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

On 5/29/25 11:05 AM, Kevin Walls wrote:
> OK thanks Philippe, and Larry -
>
> I can't provoke a problem as it stands but yes it would be good to 
> take the recommendation of the API Note, that should keep us 
> efficient. 8-)
>
> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>
> Thanks!
> Kevin
> ------------------------------------------------------------------------
> *From:* Philippe Marschall <kustos at gmx.net>
> *Sent:* Thursday, May 29, 2025 5:47 PM
> *To:* Kevin Walls <kevin.walls at oracle.com>; 
> serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
> *Subject:* [External] : Re: 
> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>
>
>
> On 29.05.25 12:21, Kevin Walls wrote:
> > Hi --
> >
> > Just to be clear, is this an actual persistent leak that we can 
> observe, or is it that we could close earlier with try-with-resources?
> > I'm not seeing a leak when calling a line like this over and over in 
> a tight loop:
> >??? final var cmdline = Files.lines(path).findFirst();
>
> I believe it is persistent until the Cleaner of FileChannel closes it.
> The #line Javadoc [1] mentions the need to close
>
> ?> This method must be used within a try-with-resources statement or
> ?> similar control structure to ensure that the stream's open file is
> ?> closed promptly after the stream's operations have completed.
>
> The Stream class Javadoc [2] explicitly mentions #lines as well
>
> ?> Generally, only streams whose source is an IO channel, such as those
> ?> returned by Files.lines(Path), will require closing. If a stream does
> ?> require closing, it must be opened as a resource within a
> ?> try-with-resources statement or similar control structure to ensure
> ?> that it is closed promptly after its operations have completed.
>
> If I run something like the code below I get
> java.nio.file.FileSystemException: marker: Too many open files. You can
> also lower the number, set a breakpoint at System.out.println and check
> /proc/<pid>/fd
>
>
> Path marker = Path.of("marker");
> if (!Files.exists(marker)) {
> ?? Files.writeString(marker, "line1");
> }
> // usually over the max fd limit
> int fileCount = 100_000;
> // prevent streams from being garbage collected and cleaner to run and
> close fd
> List<Stream<?>> streams = new ArrayList<>(fileCount);
> for (int i = 0; i < fileCount; i++) {
> ?? Stream<String> stream = Files.lines(marker);
> ?? streams.add(stream);
> ?? Optional<String> firstLine = stream.findFirst();
> ?? if (firstLine.isPresent()) {
> ???? if (firstLine.get().hashCode() == 42) {
> ?????? System.out.println('x');
> ???? }
> ?? }
> }
> System.out.println(streams.hashCode());
>
> ? [1]
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#lines(java.nio.file.Path) 
>
> ? [2]
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html 
>
>
> Regards
> Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/68ec40a7/attachment.htm>

From larry.cable at oracle.com  Thu May 29 18:59:15 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 29 May 2025 11:59:15 -0700
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>
Message-ID: <c26a850e-388a-447d-8aac-0a6e050b64a8@oracle.com>

ignore this... apologies

On 5/29/25 11:51 AM, Laurence Cable wrote:
> https://github.com/openjdk/jdk/pull/25526
>
> On 5/29/25 11:05 AM, Kevin Walls wrote:
>> OK thanks Philippe, and Larry -
>>
>> I can't provoke a problem as it stands but yes it would be good to 
>> take the recommendation of the API Note, that should keep us 
>> efficient. 8-)
>>
>> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>>
>> Thanks!
>> Kevin
>> ------------------------------------------------------------------------
>> *From:* Philippe Marschall <kustos at gmx.net>
>> *Sent:* Thursday, May 29, 2025 5:47 PM
>> *To:* Kevin Walls <kevin.walls at oracle.com>; 
>> serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
>> *Subject:* [External] : Re: 
>> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>>
>>
>>
>> On 29.05.25 12:21, Kevin Walls wrote:
>> > Hi --
>> >
>> > Just to be clear, is this an actual persistent leak that we can 
>> observe, or is it that we could close earlier with try-with-resources?
>> > I'm not seeing a leak when calling a line like this over and over 
>> in a tight loop:
>> >??? final var cmdline = Files.lines(path).findFirst();
>>
>> I believe it is persistent until the Cleaner of FileChannel closes it.
>> The #line Javadoc [1] mentions the need to close
>>
>> ?> This method must be used within a try-with-resources statement or
>> ?> similar control structure to ensure that the stream's open file is
>> ?> closed promptly after the stream's operations have completed.
>>
>> The Stream class Javadoc [2] explicitly mentions #lines as well
>>
>> ?> Generally, only streams whose source is an IO channel, such as those
>> ?> returned by Files.lines(Path), will require closing. If a stream does
>> ?> require closing, it must be opened as a resource within a
>> ?> try-with-resources statement or similar control structure to ensure
>> ?> that it is closed promptly after its operations have completed.
>>
>> If I run something like the code below I get
>> java.nio.file.FileSystemException: marker: Too many open files. You can
>> also lower the number, set a breakpoint at System.out.println and check
>> /proc/<pid>/fd
>>
>>
>> Path marker = Path.of("marker");
>> if (!Files.exists(marker)) {
>> ?? Files.writeString(marker, "line1");
>> }
>> // usually over the max fd limit
>> int fileCount = 100_000;
>> // prevent streams from being garbage collected and cleaner to run and
>> close fd
>> List<Stream<?>> streams = new ArrayList<>(fileCount);
>> for (int i = 0; i < fileCount; i++) {
>> ?? Stream<String> stream = Files.lines(marker);
>> ?? streams.add(stream);
>> ?? Optional<String> firstLine = stream.findFirst();
>> ?? if (firstLine.isPresent()) {
>> ???? if (firstLine.get().hashCode() == 42) {
>> ?????? System.out.println('x');
>> ???? }
>> ?? }
>> }
>> System.out.println(streams.hashCode());
>>
>> ? [1]
>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#lines(java.nio.file.Path) 
>>
>> ? [2]
>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html 
>>
>>
>> Regards
>> Philippe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250529/471ed8fb/attachment-0001.htm>

From amenkov at openjdk.org  Thu May 29 19:25:59 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 19:25:59 GMT
Subject: RFR: 8345745: Update mode of the Attach API communication pipe.
Message-ID: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>

Please review this small fix to update pipe mode for attach operation communication.
- `FILE_FLAG_FIRST_PIPE_INSTANCE`: there is "retry" logic if pipe creation failed [1], with this flag `CreateNamedPipe` fails when pipe with the same name already exists;
- `PIPE_REJECT_REMOTE_CLIENTS`: attach works only for local processes, the flag adds extra protection from remote connections.

[1]: https://github.com/openjdk/jdk/blob/master/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java#L93

Testing: tier1..4, hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/25530/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345745
  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25530/head:pull/25530

PR: https://git.openjdk.org/jdk/pull/25530

From amenkov at openjdk.org  Thu May 29 19:52:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 19:52:54 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <Da9jRC3NnbUWxTK64bwK8M8gVXyUllb7cF6GaNY5EUY=.f216267a-85a0-4eb5-b636-3eaa173c5ff7@github.com>

On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 458:

> 456:       fatal(jni, "JNI GetArrayLength returned a non-positive value");
> 457:     }
> 458:     jbyte* jni_arr = jni->GetByteArrayElements(arr, nullptr);

need corresponding `ReleaseByteArrayElements` call

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2114646140

From lmesnik at openjdk.org  Thu May 29 19:56:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 29 May 2025 19:56:52 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <HfyCuWxpzl07WKa8E_Uv3vRBUvX4LTJNN19nspMF5yY=.501c6d76-c326-4ab5-bbb5-fc86838a0139@github.com>

On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

Changes requested by lmesnik (Reviewer).

test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 458:

> 456:       fatal(jni, "JNI GetArrayLength returned a non-positive value");
> 457:     }
> 458:     jbyte* jni_arr = jni->GetByteArrayElements(arr, nullptr);

I think you need to release array before exit from this function to unpin it.

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

PR Review: https://git.openjdk.org/jdk/pull/25422#pullrequestreview-2879448778
PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2114651018

From cjplummer at openjdk.org  Thu May 29 20:44:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 29 May 2025 20:44:51 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
Message-ID: <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>

On Thu, 29 May 2025 18:10:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java line 83:
> 
>> 81:     private ReferenceType rType, rTypeEx;
>> 82:     private String cmd;
>> 83:     private volatile int counter1 = 0, counter2 = 0;
> 
> The volatile is not enough for increment. It might be not affect test if you check 0/non-0 only but still not a good way.
> Better to use AtomicInteger or set/read variable only.

Since there is only one writer thread, volatile should be sufficient. The only requirement is to make writes visible to the reader thread. volatile accomplishes that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114719187

From lmesnik at openjdk.org  Thu May 29 21:20:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 29 May 2025 21:20:56 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
 <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>
Message-ID: <I8sQ1ugL5Obgg6JTkWzz-kKNbyKXPzvelCkKyuw4xSU=.b32a1392-037c-4310-a478-e7c6cc914180@github.com>

On Thu, 29 May 2025 20:42:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java line 83:
>> 
>>> 81:     private ReferenceType rType, rTypeEx;
>>> 82:     private String cmd;
>>> 83:     private volatile int counter1 = 0, counter2 = 0;
>> 
>> The volatile is not enough for increment. It might be not affect test if you check 0/non-0 only but still not a good way.
>> Better to use AtomicInteger or set/read variable only.
>
> Since there is only one writer thread, volatile should be sufficient. The only requirement is to make writes visible to the reader thread. volatile accomplishes that.

Thanks for explanation. Can you please add corresponding comment. The volatile counters are rare thing...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114765521

From amenkov at openjdk.org  Thu May 29 21:41:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 May 2025 21:41:51 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <I8sQ1ugL5Obgg6JTkWzz-kKNbyKXPzvelCkKyuw4xSU=.b32a1392-037c-4310-a478-e7c6cc914180@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
 <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>
 <I8sQ1ugL5Obgg6JTkWzz-kKNbyKXPzvelCkKyuw4xSU=.b32a1392-037c-4310-a478-e7c6cc914180@github.com>
Message-ID: <SEZ04-gB_T1PAp2oeqHyxEsoAnXX_KEnO5kqFN3wL30=.488ec5f9-0c16-42d1-ab23-c9e9e031ebf8@github.com>

On Thu, 29 May 2025 21:18:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Since there is only one writer thread, volatile should be sufficient. The only requirement is to make writes visible to the reader thread. volatile accomplishes that.
>
> Thanks for explanation. Can you please add corresponding comment. The volatile counters are rare thing...

I think the evaluation is not correct (lack of synchronization is an issue too).
main thread also writes the value and I think this is the problem here.
Look at line 148 - it resets `counter1` instead of `counter2` and this happens after the test sends `COMMAND_TEST1`. So if listener thread already handled caught exception, we get the failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114790682

From jbechberger at openjdk.org  Thu May 29 21:56:21 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 29 May 2025 21:56:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix tiny issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/adcbec51..16faa421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=22-23

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

PR: https://git.openjdk.org/jdk/pull/25302

From cjplummer at openjdk.org  Fri May 30 01:14:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 01:14:52 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <SEZ04-gB_T1PAp2oeqHyxEsoAnXX_KEnO5kqFN3wL30=.488ec5f9-0c16-42d1-ab23-c9e9e031ebf8@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
 <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>
 <I8sQ1ugL5Obgg6JTkWzz-kKNbyKXPzvelCkKyuw4xSU=.b32a1392-037c-4310-a478-e7c6cc914180@github.com>
 <SEZ04-gB_T1PAp2oeqHyxEsoAnXX_KEnO5kqFN3wL30=.488ec5f9-0c16-42d1-ab23-c9e9e031ebf8@github.com>
Message-ID: <oMODD2uxsLCc8kqGaQY_feLYtn5FkB0TmGqeWT4kbTY=.2ea51abe-4217-4b05-b469-e89ffbc1becd@github.com>

On Thu, 29 May 2025 21:39:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Thanks for explanation. Can you please add corresponding comment. The volatile counters are rare thing...
>
> I think the evaluation is not correct (lack of synchronization is an issue too).
> main thread also writes the value and I think this is the problem here.
> Look at line 148 - it resets `counter1` instead of `counter2` and this happens after the test sends `COMMAND_TEST1`. So if listener thread already handled caught exception, we get the failure.

Yes, I noticed that, and I think the resetting is a bug. Probably left over from when the test was originally written. I think both of those resets can be removed. It only makes sense to reset the counters if first you check them and produce an error if one of them was unexpectedly set. For example, after the the first part of the test counter1 should be 1 and counter2 should be zero. After making that check, both counters should be reset. After the 2nd part it should verify that counter1 is 0 and counter2 is 1. However, this test does not have the needed synchronization to make those types of checks. So instead it waits for the debuggee to exit and then checks that both counters are not 0. Also, it could (should) just check for 1 intead. There should never be more than one of each exception event generated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114976126

From cjplummer at openjdk.org  Fri May 30 01:48:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 01:48:01 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <oMODD2uxsLCc8kqGaQY_feLYtn5FkB0TmGqeWT4kbTY=.2ea51abe-4217-4b05-b469-e89ffbc1becd@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <76uAqyPop_aXK27OKucJ-7QZ5AuqzndgkpD7hwjrxg0=.e6bbe119-5713-4c7d-af73-63adfe4f61ad@github.com>
 <OohnGIEIwNuCwJakunLNHV99Lv6xwAyx5gPB9xqxLgQ=.936552d8-1c54-407c-8bb3-6b8c554bc5b0@github.com>
 <I8sQ1ugL5Obgg6JTkWzz-kKNbyKXPzvelCkKyuw4xSU=.b32a1392-037c-4310-a478-e7c6cc914180@github.com>
 <SEZ04-gB_T1PAp2oeqHyxEsoAnXX_KEnO5kqFN3wL30=.488ec5f9-0c16-42d1-ab23-c9e9e031ebf8@github.com>
 <oMODD2uxsLCc8kqGaQY_feLYtn5FkB0TmGqeWT4kbTY=.2ea51abe-4217-4b05-b469-e89ffbc1becd@github.com>
Message-ID: <rPLSz01-t0pSVJYKaXUdFFBJx33QT67kZoUgdX1Oz0A=.56423cef-b60d-4239-9357-9b028af76ced@github.com>

On Fri, 30 May 2025 01:12:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I think the evaluation is not correct (lack of synchronization is an issue too).
>> main thread also writes the value and I think this is the problem here.
>> Look at line 148 - it resets `counter1` instead of `counter2` and this happens after the test sends `COMMAND_TEST1`. So if listener thread already handled caught exception, we get the failure.
>
> Yes, I noticed that, and I think the resetting is a bug. Probably left over from when the test was originally written. I think both of those resets can be removed. It only makes sense to reset the counters if first you check them and produce an error if one of them was unexpectedly set. For example, after the the first part of the test counter1 should be 1 and counter2 should be zero. After making that check, both counters should be reset. After the 2nd part it should verify that counter1 is 0 and counter2 is 1. However, this test does not have the needed synchronization to make those types of checks. So instead it waits for the debuggee to exit and then checks that both counters are not 0. Also, it could (should) just check for 1 intead. There should never be more than one of each exception event generated.

Actually the 2nd exception is received twice, but this is also a bug. When using the vthread wrapper, an exception handler is added which catches the exception and then rethrows it, so we get two ExceptionEvents for this event. If the test was a bit more thorough, it would be verifying that the exception is indeed uncaught, and fail if it isnot, but then we'd have to start excluding this test with vthread testing (and no real way of fixing it).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2115000668

From cjplummer at openjdk.org  Fri May 30 03:15:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 03:15:40 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception [v2]
In-Reply-To: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
Message-ID: <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>

> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  cleaned up event counters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25236/files
  - new: https://git.openjdk.org/jdk/pull/25236/files/ef35ffa9..1304cd72

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

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

PR: https://git.openjdk.org/jdk/pull/25236

From sspitsyn at openjdk.org  Fri May 30 05:29:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 05:29:05 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25422/files
  - new: https://git.openjdk.org/jdk/pull/25422/files/05bbcf5a..9f128798

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

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

PR: https://git.openjdk.org/jdk/pull/25422

From lmesnik at openjdk.org  Fri May 30 05:29:05 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 May 2025 05:29:05 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>
Message-ID: <7UptIQHnCxN3J85ZtQe7RPKN-8XQiKIbxhFx7cwSQN4=.190ef40c-afa3-4692-b3d3-91b5f5b07aaf@github.com>

On Fri, 30 May 2025 05:25:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
>> 
>>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
>> 
>> Please, see the JVMTI ClassFileLoadHook spec:
>>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
>> 
>> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
>> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
>> 
>> Testing:
>>  - ran updated tests individually
>>  - TBD: submit mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25422#pullrequestreview-2880210247

From sspitsyn at openjdk.org  Fri May 30 05:29:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 05:29:05 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <HfyCuWxpzl07WKa8E_Uv3vRBUvX4LTJNN19nspMF5yY=.501c6d76-c326-4ab5-bbb5-fc86838a0139@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <HfyCuWxpzl07WKa8E_Uv3vRBUvX4LTJNN19nspMF5yY=.501c6d76-c326-4ab5-bbb5-fc86838a0139@github.com>
Message-ID: <koTvtuYGVXePWPKylFz0X0NTydFLMPb62UTZN0YPyM4=.40b391f6-474e-420e-91cf-132c57599caa@github.com>

On Thu, 29 May 2025 19:53:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated
>
> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 458:
> 
>> 456:       fatal(jni, "JNI GetArrayLength returned a non-positive value");
>> 457:     }
>> 458:     jbyte* jni_arr = jni->GetByteArrayElements(arr, nullptr);
> 
> I think you need to release array before exit from this function to unpin it.

Good catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2115161303

From sspitsyn at openjdk.org  Fri May 30 05:29:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 05:29:06 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <Da9jRC3NnbUWxTK64bwK8M8gVXyUllb7cF6GaNY5EUY=.f216267a-85a0-4eb5-b636-3eaa173c5ff7@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <Da9jRC3NnbUWxTK64bwK8M8gVXyUllb7cF6GaNY5EUY=.f216267a-85a0-4eb5-b636-3eaa173c5ff7@github.com>
Message-ID: <v6MGZRGQ8pgI1tnX4-SPoa_LDKcQYGALUOHMTdVJdAM=.a4afcaf4-09a5-470a-a401-227125057d56@github.com>

On Thu, 29 May 2025 19:50:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated
>
> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 458:
> 
>> 456:       fatal(jni, "JNI GetArrayLength returned a non-positive value");
>> 457:     }
>> 458:     jbyte* jni_arr = jni->GetByteArrayElements(arr, nullptr);
> 
> need corresponding `ReleaseByteArrayElements` call

Good catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2115163012

From dtabata at openjdk.org  Fri May 30 09:07:59 2025
From: dtabata at openjdk.org (Daishi Tabata)
Date: Fri, 30 May 2025 09:07:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
Message-ID: <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>

On Thu, 29 May 2025 21:56:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tiny issue

src/hotspot/share/jfr/metadata/metadata.xml line 975:

> 973:   </Event>
> 974: 
> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples"

I'm not a reviewer, but I just wanted to comment something I noticed.
The JEP document says CPUTimeSampleLos'**t**', but the implementation says CPUTimeSampleLos'**s**'. Which one is correct?
A sentence from the JEP document:

Another new event,?`jdk.CPUTimeSampleLost`, is emitted when samples are lost ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2115464262

From jbechberger at openjdk.org  Fri May 30 09:23:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 30 May 2025 09:23:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
 <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
Message-ID: <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>

On Fri, 30 May 2025 09:04:44 GMT, Daishi Tabata <dtabata at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tiny issue
>
> src/hotspot/share/jfr/metadata/metadata.xml line 975:
> 
>> 973:   </Event>
>> 974: 
>> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples"
> 
> I'm not a reviewer, but I just wanted to comment something I noticed.
> The JEP document says CPUTimeSampleLos'**t**', but the implementation says CPUTimeSampleLos'**s**'. Which one is correct?
> A sentence from the JEP document:
> 
> Another new event,?`jdk.CPUTimeSampleLost`, is emitted when samples are lost ...

Thanks for catching this mistake. I'll fix it this afternoon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2115488808

From sspitsyn at openjdk.org  Fri May 30 10:12:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 10:12:51 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception [v2]
In-Reply-To: <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
Message-ID: <LS6r9nU1lFnHdjEwkJmV7ZVZc2OLRKjbuinHDMC0d-c=.493dd18a-4039-4fc9-a222-4b207980cb44@github.com>

On Fri, 30 May 2025 03:15:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up event counters

The fix looks good. Also, I have no objections against adding a comment.
The event listener thread sets the flags and the main thread checks them.
Making flags volatile should be enough.
Clearing the flags in the main thread was also a bug before the fix.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25236#pullrequestreview-2880848984

From jbechberger at openjdk.org  Fri May 30 10:17:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 30 May 2025 10:17:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove debug printf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/16faa421..3a10d552

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=23-24

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

PR: https://git.openjdk.org/jdk/pull/25302

From sspitsyn at openjdk.org  Fri May 30 10:34:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 10:34:52 GMT
Subject: RFR: 8345745: Update mode of the Attach API communication pipe.
In-Reply-To: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
References: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
Message-ID: <UTY4NHGQIbeQQA-p33jWRF3BcnhR0RO1Ap4Z9ge7zqU=.c2a3bbb6-43db-4d02-8515-7f5d2b71dd71@github.com>

On Thu, 29 May 2025 19:21:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this small fix to update pipe mode for attach operation communication.
> - `FILE_FLAG_FIRST_PIPE_INSTANCE`: there is "retry" logic if pipe creation failed [1], with this flag `CreateNamedPipe` fails when pipe with the same name already exists;
> - `PIPE_REJECT_REMOTE_CLIENTS`: attach works only for local processes, the flag adds extra protection from remote connections.
> 
> [1]: https://github.com/openjdk/jdk/blob/master/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java#L93
> 
> Testing: tier1..4, hs-tier5-svc

Looks good to me (according to these flags description).

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25530#pullrequestreview-2880909328

From vyazici at openjdk.org  Fri May 30 10:55:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 10:55:26 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot]
Message-ID: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.

-------------

Commit messages:
 - Remove redundant assert
 - Discard changes unrelated with build and tools
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357993
  Stats: 13 lines in 4 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25542/head:pull/25542

PR: https://git.openjdk.org/jdk/pull/25542

From rvansa at openjdk.org  Fri May 30 11:08:19 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 11:08:19 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v11]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <WrvnIAEOkPYCcznWix24hGB_tkTQ5sji1jl9a8P7o_Y=.76e0014a-b686-4677-8f44-1892c7ed3c07@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - CI debug only: detailed msg
 - Add include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/8c2c8334..a2d199bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=09-10

  Stats: 22 lines in 3 files changed: 17 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From vyazici at openjdk.org  Fri May 30 11:12:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 11:12:15 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
Message-ID: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

-------------

Commit messages:
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357995
  Stats: 65 lines in 15 files changed: 16 ins; 7 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

PR: https://git.openjdk.org/jdk/pull/25544

From rvansa at openjdk.org  Fri May 30 11:56:44 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 11:56:44 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v12]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <5tF9oyhymxgS2UUrMWa5WMjB4-aRQ0jjRLgk80mDNqs=.0e5df0d9-fd81-43e2-b347-e567b3131d58@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  WIP debugging

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/a2d199bc..9fdc2d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=10-11

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From kustos at gmx.net  Fri May 30 11:58:31 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Fri, 30 May 2025 13:58:31 +0200
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <c26a850e-388a-447d-8aac-0a6e050b64a8@oracle.com>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>
 <c26a850e-388a-447d-8aac-0a6e050b64a8@oracle.com>
Message-ID: <5332c355-2fbf-47dd-a4da-901d78be9cb5@gmx.net>

Should I open the PR? I think we're all pretty much in agreement 
regarding the fix.

Cheers
Philippe

On 29.05.25 20:59, Laurence Cable wrote:
> ignore this... apologies
> 
> On 5/29/25 11:51 AM, Laurence Cable wrote:
>> https://github.com/openjdk/jdk/pull/25526
>>
>> On 5/29/25 11:05 AM, Kevin Walls wrote:
>>> OK thanks Philippe, and Larry -
>>>
>>> I can't provoke a problem as it stands but yes it would be good to 
>>> take the recommendation of the API Note, that should keep us 
>>> efficient. 8-)
>>>
>>> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>>>
>>> Thanks!
>>> Kevin
>>> ------------------------------------------------------------------------
>>> *From:* Philippe Marschall <kustos at gmx.net>
>>> *Sent:* Thursday, May 29, 2025 5:47 PM
>>> *To:* Kevin Walls <kevin.walls at oracle.com>; serviceability- 
>>> dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
>>> *Subject:* [External] : Re: 
>>> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>>>
>>>
>>>
>>> On 29.05.25 12:21, Kevin Walls wrote:
>>> > Hi --
>>> >
>>> > Just to be clear, is this an actual persistent leak that we can 
>>> observe, or is it that we could close earlier with try-with-resources?
>>> > I'm not seeing a leak when calling a line like this over and over 
>>> in a tight loop:
>>> >??? final var cmdline = Files.lines(path).findFirst();
>>>
>>> I believe it is persistent until the Cleaner of FileChannel closes it.
>>> The #line Javadoc [1] mentions the need to close
>>>
>>> ?> This method must be used within a try-with-resources statement or
>>> ?> similar control structure to ensure that the stream's open file is
>>> ?> closed promptly after the stream's operations have completed.
>>>
>>> The Stream class Javadoc [2] explicitly mentions #lines as well
>>>
>>> ?> Generally, only streams whose source is an IO channel, such as those
>>> ?> returned by Files.lines(Path), will require closing. If a stream does
>>> ?> require closing, it must be opened as a resource within a
>>> ?> try-with-resources statement or similar control structure to ensure
>>> ?> that it is closed promptly after its operations have completed.
>>>
>>> If I run something like the code below I get
>>> java.nio.file.FileSystemException: marker: Too many open files. You can
>>> also lower the number, set a breakpoint at System.out.println and check
>>> /proc/<pid>/fd
>>>
>>>
>>> Path marker = Path.of("marker");
>>> if (!Files.exists(marker)) {
>>> ?? Files.writeString(marker, "line1");
>>> }
>>> // usually over the max fd limit
>>> int fileCount = 100_000;
>>> // prevent streams from being garbage collected and cleaner to run and
>>> close fd
>>> List<Stream<?>> streams = new ArrayList<>(fileCount);
>>> for (int i = 0; i < fileCount; i++) {
>>> ?? Stream<String> stream = Files.lines(marker);
>>> ?? streams.add(stream);
>>> ?? Optional<String> firstLine = stream.findFirst();
>>> ?? if (firstLine.isPresent()) {
>>> ???? if (firstLine.get().hashCode() == 42) {
>>> ?????? System.out.println('x');
>>> ???? }
>>> ?? }
>>> }
>>> System.out.println(streams.hashCode());
>>>
>>> ? [1]
>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>> nio/file/Files.html#lines(java.nio.file.Path)
>>> ? [2]
>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>> util/stream/Stream.html
>>>
>>> Regards
>>> Philippe
>>
> 


From rvansa at openjdk.org  Fri May 30 12:31:48 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 12:31:48 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v13]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <X0dk4ING85Ll8fT9OwsN7N3pLsr6F3tHPc7LJVKQtPs=.51b6e432-2f20-43ce-96e9-e7fd71cba289@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Fix static_assert
 - debug logs fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/9fdc2d0a..479a84ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=11-12

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From rvansa at openjdk.org  Fri May 30 13:20:41 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 13:20:41 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v14]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <7gnetOo26HmQgTxh6eMuT-287j96ipiqtPj4BDX1Qm4=.387172de-a3d0-4e97-8b38-729dca576124@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Verbose logs before crash

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/479a84ed..d8a1d0f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=12-13

  Stats: 23 lines in 1 file changed: 14 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From weijun at openjdk.org  Fri May 30 13:46:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 May 2025 13:46:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922441338

From kevinw at openjdk.org  Fri May 30 14:01:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 May 2025 14:01:57 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v7]
In-Reply-To: <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
Message-ID: <_AT98VpWvNBQGgO8kAT5GMWoBbSsx-v8HazgyshJ_HA=.4dc5cbc1-3cb6-4ba2-bb15-2aad5d738701@github.com>

On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Just to be clear, the ifdef JVMTI means Thread.dump_to_file not work in a build configuration using - --enable-jvm-feature-jvmti=no ?
Currently, Thread.dump_to_file works in such configs.  
I don't think this is a problem.. just thought we could spell it out.
This all looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2922476663

From vyazici at openjdk.org  Fri May 30 14:01:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 14:01:55 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
Message-ID: <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>

On Fri, 30 May 2025 13:44:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922477202

From coleenp at openjdk.org  Fri May 30 14:09:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 May 2025 14:09:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v14]
In-Reply-To: <7gnetOo26HmQgTxh6eMuT-287j96ipiqtPj4BDX1Qm4=.387172de-a3d0-4e97-8b38-729dca576124@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <7gnetOo26HmQgTxh6eMuT-287j96ipiqtPj4BDX1Qm4=.387172de-a3d0-4e97-8b38-729dca576124@github.com>
Message-ID: <Chn4FYkNS1wOvpOK72ksmrTlpP5CtpqoZu07IXxMYJ0=.edf999d5-da5f-4a8c-a0cf-f9d0dcd47654@github.com>

On Fri, 30 May 2025 13:20:41 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Verbose logs before crash

I am coming back to review this but there are GHA failures.  Can you fix those first? thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2922497970

From alanb at openjdk.org  Fri May 30 14:21:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:21:53 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v7]
In-Reply-To: <_AT98VpWvNBQGgO8kAT5GMWoBbSsx-v8HazgyshJ_HA=.4dc5cbc1-3cb6-4ba2-bb15-2aad5d738701@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
 <_AT98VpWvNBQGgO8kAT5GMWoBbSsx-v8HazgyshJ_HA=.4dc5cbc1-3cb6-4ba2-bb15-2aad5d738701@github.com>
Message-ID: <Ol-gejnNOpCGwEuGN0tOyhd2Np7mZynPEWRKeAs7zFQ=.a3e538a7-d450-4868-bfb6-7606964c7584@github.com>

On Fri, 30 May 2025 13:58:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Just to be clear, the ifdef JVMTI means Thread.dump_to_file not work in a build configuration using - --enable-jvm-feature-jvmti=no ? Currently, Thread.dump_to_file works in such configs. I don't think this is a problem.. just thought we could spell it out. This all looks good to me.

The dependency on JvmtiVTMSTransitionDisabler is needed but now but maybe in the future this could be separated from JVMTI for other cases where transitions needs to be disabled.

Minimal VM disables management and jvmti, and is really only practical if you run jlink to create a run-time image with a small subset of the modules. So no jdk.management and no HotSpotDiagnosticMXBean. It's possible of course that someone configures with +management and -jvmti, in which case the HotSpotDiagnosticMXBean.dumpThreads will throw NPE. It should throw UOE (the method is specified to allow this), which means JVM_CreateThreadSnapshot or ThreadSnapshot.of(Thread) should throw.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2922530490

From alanb at openjdk.org  Fri May 30 14:27:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:27:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

test/jdk/com/sun/tools/attach/Application.java line 40:

> 38: 
> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
> 40:                 System.in, System.getProperty("stdin.encoding")))) {

This "application" is launched by the test so connected to the parent process rather than the console.

test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:

> 313:                         // children and wait for each to exit
> 314:                         sendResult(action, "start");
> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116027806
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116031061

From rvansa at openjdk.org  Fri May 30 14:34:45 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 14:34:45 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  More debug logs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/d8a1d0f9..70f62460

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=13-14

  Stats: 20 lines in 3 files changed: 19 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

PR: https://git.openjdk.org/jdk/pull/24847

From kevinw at openjdk.org  Fri May 30 14:52:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 May 2025 14:52:56 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps [v7]
In-Reply-To: <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
 <pVT7N4RQbOGxLutlOEpGd49T7UEiOibjiRRLRBmTJUM=.9b081872-7e61-4b05-9a4e-353433ead23e@github.com>
Message-ID: <E-IfIbLcJ8P4XJhgenGW8CYcbCvo95dgc9ZfUbpD7s8=.41d3ee29-a948-4fa4-8372-b25b277f84ec@github.com>

On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewing.
>> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
>> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
>> 
>> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>>   sanity tier1 (this fix only)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by kevinw (Reviewer).

Thanks Alan, and thanks Alex!

-------------

PR Review: https://git.openjdk.org/jdk/pull/25425#pullrequestreview-2881602072
PR Comment: https://git.openjdk.org/jdk/pull/25425#issuecomment-2922608832

From larry.cable at oracle.com  Fri May 30 15:02:52 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Fri, 30 May 2025 08:02:52 -0700
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <5332c355-2fbf-47dd-a4da-901d78be9cb5@gmx.net>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>
 <c26a850e-388a-447d-8aac-0a6e050b64a8@oracle.com>
 <5332c355-2fbf-47dd-a4da-901d78be9cb5@gmx.net>
Message-ID: <7c95277b-201d-483c-bc24-0f056b1b4a42@oracle.com>

Ive already done it...

On 5/30/25 4:58 AM, Philippe Marschall wrote:
> Should I open the PR? I think we're all pretty much in agreement 
> regarding the fix.
>
> Cheers
> Philippe
>
> On 29.05.25 20:59, Laurence Cable wrote:
>> ignore this... apologies
>>
>> On 5/29/25 11:51 AM, Laurence Cable wrote:
>>> https://github.com/openjdk/jdk/pull/25526
>>>
>>> On 5/29/25 11:05 AM, Kevin Walls wrote:
>>>> OK thanks Philippe, and Larry -
>>>>
>>>> I can't provoke a problem as it stands but yes it would be good to 
>>>> take the recommendation of the API Note, that should keep us 
>>>> efficient. 8-)
>>>>
>>>> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>>>>
>>>> Thanks!
>>>> Kevin
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> *From:* Philippe Marschall <kustos at gmx.net>
>>>> *Sent:* Thursday, May 29, 2025 5:47 PM
>>>> *To:* Kevin Walls <kevin.walls at oracle.com>; serviceability- 
>>>> dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
>>>> *Subject:* [External] : Re: 
>>>> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>>>>
>>>>
>>>>
>>>> On 29.05.25 12:21, Kevin Walls wrote:
>>>> > Hi --
>>>> >
>>>> > Just to be clear, is this an actual persistent leak that we can 
>>>> observe, or is it that we could close earlier with try-with-resources?
>>>> > I'm not seeing a leak when calling a line like this over and over 
>>>> in a tight loop:
>>>> >??? final var cmdline = Files.lines(path).findFirst();
>>>>
>>>> I believe it is persistent until the Cleaner of FileChannel closes it.
>>>> The #line Javadoc [1] mentions the need to close
>>>>
>>>> ?> This method must be used within a try-with-resources statement or
>>>> ?> similar control structure to ensure that the stream's open file is
>>>> ?> closed promptly after the stream's operations have completed.
>>>>
>>>> The Stream class Javadoc [2] explicitly mentions #lines as well
>>>>
>>>> ?> Generally, only streams whose source is an IO channel, such as 
>>>> those
>>>> ?> returned by Files.lines(Path), will require closing. If a stream 
>>>> does
>>>> ?> require closing, it must be opened as a resource within a
>>>> ?> try-with-resources statement or similar control structure to ensure
>>>> ?> that it is closed promptly after its operations have completed.
>>>>
>>>> If I run something like the code below I get
>>>> java.nio.file.FileSystemException: marker: Too many open files. You 
>>>> can
>>>> also lower the number, set a breakpoint at System.out.println and 
>>>> check
>>>> /proc/<pid>/fd
>>>>
>>>>
>>>> Path marker = Path.of("marker");
>>>> if (!Files.exists(marker)) {
>>>> ?? Files.writeString(marker, "line1");
>>>> }
>>>> // usually over the max fd limit
>>>> int fileCount = 100_000;
>>>> // prevent streams from being garbage collected and cleaner to run and
>>>> close fd
>>>> List<Stream<?>> streams = new ArrayList<>(fileCount);
>>>> for (int i = 0; i < fileCount; i++) {
>>>> ?? Stream<String> stream = Files.lines(marker);
>>>> ?? streams.add(stream);
>>>> ?? Optional<String> firstLine = stream.findFirst();
>>>> ?? if (firstLine.isPresent()) {
>>>> ???? if (firstLine.get().hashCode() == 42) {
>>>> ?????? System.out.println('x');
>>>> ???? }
>>>> ?? }
>>>> }
>>>> System.out.println(streams.hashCode());
>>>>
>>>> ? [1]
>>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>>> nio/file/Files.html#lines(java.nio.file.Path)
>>>> ? [2]
>>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>>> util/stream/Stream.html
>>>>
>>>> Regards
>>>> Philippe
>>>
>>
>


From lmesnik at openjdk.org  Fri May 30 15:03:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 May 2025 15:03:58 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception [v2]
In-Reply-To: <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
Message-ID: <CYPe9_Bceid4oLarBoEE9n1q-TfobNzKSGuGXOfcGxw=.eb4febb1-969a-4557-9a67-8300d6f7e106@github.com>

On Fri, 30 May 2025 03:15:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up event counters

Thanks for fixing, now it is clear that volatile is enough.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25236#pullrequestreview-2881627854
PR Review: https://git.openjdk.org/jdk/pull/25236#pullrequestreview-2881628214

From rvansa at openjdk.org  Fri May 30 15:13:58 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 30 May 2025 15:13:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
Message-ID: <MxI7-4-CEj7jxVyh5o8Wt75ZCy8L998dVtdP3xNLiv4=.1f2f55e6-91f3-4906-a4fa-4d6e90bab589@github.com>

On Fri, 30 May 2025 14:34:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More debug logs

Apologies for the noise (debugging commits), I cannot reproduce the failure locally. I'll continue investigation on Monday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2922662884

From alanb at openjdk.org  Fri May 30 15:16:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 15:16:54 GMT
Subject: RFR: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads [v2]
In-Reply-To: <5NP780d1JpO89jffeMRPkT6Adqp29ttmwYKNP3gg18c=.2c3733d4-da7e-45eb-b37c-006de28783bf@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
 <5NP780d1JpO89jffeMRPkT6Adqp29ttmwYKNP3gg18c=.2c3733d4-da7e-45eb-b37c-006de28783bf@github.com>
Message-ID: <c7iMBbGy4kkni1oj4axLN3dN4dLW7GA4xiAhJAuqDfE=.56dbb4da-44c1-48ce-a753-42c047f6a311@github.com>

On Wed, 28 May 2025 01:25:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
>> 
>> Testing: new test, tier1 sanity run
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25367#pullrequestreview-2881663778

From duke at openjdk.org  Fri May 30 16:20:02 2025
From: duke at openjdk.org (Larry Cable)
Date: Fri, 30 May 2025 16:20:02 GMT
Subject: RFR: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
Message-ID: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>

JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114

modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

-------------

Commit messages:
 - JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114

Changes: https://git.openjdk.org/jdk/pull/25529/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25529&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358077
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25529/head:pull/25529

PR: https://git.openjdk.org/jdk/pull/25529

From kevinw at openjdk.org  Fri May 30 16:39:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 May 2025 16:39:52 GMT
Subject: RFR: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
In-Reply-To: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
References: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
Message-ID: <Zwg2F8DLbbhnOffS8iIxlHtI1PDXtbt6DDo_hIKBUQs=.cc8f38b8-6156-461a-b403-6e062717aee1@github.com>

On Thu, 29 May 2025 19:14:06 GMT, Larry Cable <duke at openjdk.org> wrote:

> JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114
> 
> modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

Looks good.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25529#pullrequestreview-2881867412

From kevinw at openjdk.org  Fri May 30 17:01:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 May 2025 17:01:57 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
Message-ID: <zSB94sABhXIwS_Kfhg8qLE-0Tqrl9FpNgWf-fgSkkNk=.3888a090-a090-4d1d-bf39-f1c6a4039d27@github.com>

On Thu, 29 May 2025 10:15:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Initial commit

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 96:

> 94:      * Generate a thread dump in plain text or JSON format to a byte array, UTF-8 encoded.
> 95:      * This method is the implementation of the Thread.dump_to_file diagnostic command
> 96:      * when a file path is not specified. It returns the thread and/or message to send

Comment nit: maybe "...returns the thread dump text and/or message..."?
(also line 120)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116269128

From larry.cable at oracle.com  Fri May 30 17:17:42 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Fri, 30 May 2025 10:17:42 -0700
Subject: [External] : Re: VirtualMachineImpl.checkCatchesAndSendQuitTo
 leaks file handles
In-Reply-To: <5332c355-2fbf-47dd-a4da-901d78be9cb5@gmx.net>
References: <9f0690fd-8fd1-4dc4-8304-e31f85138923@gmx.net>
 <SN7PR10MB7032F08474EA328AF169C96B9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <5b63c33c-cbc0-45c8-a869-d5b67ea91a98@gmx.net>
 <SN7PR10MB703286AF1A6FC40CA057C19E9766A@SN7PR10MB7032.namprd10.prod.outlook.com>
 <df4db791-c12f-4181-9cf5-ff42499003a3@oracle.com>
 <c26a850e-388a-447d-8aac-0a6e050b64a8@oracle.com>
 <5332c355-2fbf-47dd-a4da-901d78be9cb5@gmx.net>
Message-ID: <b7f86994-257d-49a3-8afc-0b087ab8826a@oracle.com>

https://git.openjdk.org/jdk/pull/25529

On 5/30/25 4:58 AM, Philippe Marschall wrote:
> Should I open the PR? I think we're all pretty much in agreement 
> regarding the fix.
>
> Cheers
> Philippe
>
> On 29.05.25 20:59, Laurence Cable wrote:
>> ignore this... apologies
>>
>> On 5/29/25 11:51 AM, Laurence Cable wrote:
>>> https://github.com/openjdk/jdk/pull/25526
>>>
>>> On 5/29/25 11:05 AM, Kevin Walls wrote:
>>>> OK thanks Philippe, and Larry -
>>>>
>>>> I can't provoke a problem as it stands but yes it would be good to 
>>>> take the recommendation of the API Note, that should keep us 
>>>> efficient. 8-)
>>>>
>>>> I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
>>>>
>>>> Thanks!
>>>> Kevin
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> *From:* Philippe Marschall <kustos at gmx.net>
>>>> *Sent:* Thursday, May 29, 2025 5:47 PM
>>>> *To:* Kevin Walls <kevin.walls at oracle.com>; serviceability- 
>>>> dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
>>>> *Subject:* [External] : Re: 
>>>> VirtualMachineImpl.checkCatchesAndSendQuitTo leaks file handles
>>>>
>>>>
>>>>
>>>> On 29.05.25 12:21, Kevin Walls wrote:
>>>> > Hi --
>>>> >
>>>> > Just to be clear, is this an actual persistent leak that we can 
>>>> observe, or is it that we could close earlier with try-with-resources?
>>>> > I'm not seeing a leak when calling a line like this over and over 
>>>> in a tight loop:
>>>> >??? final var cmdline = Files.lines(path).findFirst();
>>>>
>>>> I believe it is persistent until the Cleaner of FileChannel closes it.
>>>> The #line Javadoc [1] mentions the need to close
>>>>
>>>> ?> This method must be used within a try-with-resources statement or
>>>> ?> similar control structure to ensure that the stream's open file is
>>>> ?> closed promptly after the stream's operations have completed.
>>>>
>>>> The Stream class Javadoc [2] explicitly mentions #lines as well
>>>>
>>>> ?> Generally, only streams whose source is an IO channel, such as 
>>>> those
>>>> ?> returned by Files.lines(Path), will require closing. If a stream 
>>>> does
>>>> ?> require closing, it must be opened as a resource within a
>>>> ?> try-with-resources statement or similar control structure to ensure
>>>> ?> that it is closed promptly after its operations have completed.
>>>>
>>>> If I run something like the code below I get
>>>> java.nio.file.FileSystemException: marker: Too many open files. You 
>>>> can
>>>> also lower the number, set a breakpoint at System.out.println and 
>>>> check
>>>> /proc/<pid>/fd
>>>>
>>>>
>>>> Path marker = Path.of("marker");
>>>> if (!Files.exists(marker)) {
>>>> ?? Files.writeString(marker, "line1");
>>>> }
>>>> // usually over the max fd limit
>>>> int fileCount = 100_000;
>>>> // prevent streams from being garbage collected and cleaner to run and
>>>> close fd
>>>> List<Stream<?>> streams = new ArrayList<>(fileCount);
>>>> for (int i = 0; i < fileCount; i++) {
>>>> ?? Stream<String> stream = Files.lines(marker);
>>>> ?? streams.add(stream);
>>>> ?? Optional<String> firstLine = stream.findFirst();
>>>> ?? if (firstLine.isPresent()) {
>>>> ???? if (firstLine.get().hashCode() == 42) {
>>>> ?????? System.out.println('x');
>>>> ???? }
>>>> ?? }
>>>> }
>>>> System.out.println(streams.hashCode());
>>>>
>>>> ? [1]
>>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>>> nio/file/Files.html#lines(java.nio.file.Path)
>>>> ? [2]
>>>> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/ 
>>>> util/stream/Stream.html
>>>>
>>>> Regards
>>>> Philippe
>>>
>>
>


From cjplummer at openjdk.org  Fri May 30 17:39:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 17:39:00 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
 includevirtualthreads=y [v10]
In-Reply-To: <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
 <BdVWE-vOOjlylSQ2BI0xZeUTvgkNR_p0d48WFZh0PO0=.646f3723-9390-4fa6-8865-5f475d001b91@github.com>
Message-ID: <WQuv4e-oIAcJmB6hd31s-SUuzLGWdmGKoYwjWBpE01M=.b3d24497-b472-4fa4-91d2-6f1e8e0db90a@github.com>

On Tue, 20 May 2025 19:33:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
>> 
>> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
>> 
>> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo errant copyright updates
>  - undo errant copyright updates

Thank you for the reviews Alex, Serguei, and Leonid.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2922987133

From cjplummer at openjdk.org  Fri May 30 17:39:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 17:39:01 GMT
Subject: Integrated: 8353955: nsk/jdi tests should be fixed to not always
 require includevirtualthreads=y
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <j7-6cDdT8y3rlkA9IMVhNqNbTYx6ShhSPjW63LtENzI=.e8e114fa-bd07-4af9-baff-a34dedf55ea1@github.com>

On Fri, 11 Apr 2025 23:23:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
> 
> There are nearly 1200 nsk/jdi tests. There were about 350 tests that actually needed includevirtualthreads=y, but most of these have been addressed by other PRs, leaving the 20 or so tests being addressed in this PR. With this PR now defaulting to includevirtualthreads=n, the tests that require includevirtualthreads=y need to override the default by specifying the -includevirtualthreads @run option.

This pull request has now been integrated.

Changeset: 3cc63098
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cc630985d47be6ba4cf991698e999f17dbde203
Stats:     72 lines in 25 files changed: 37 ins; 0 del; 35 mod

8353955: nsk/jdi tests should be fixed to not always require includevirtualthreads=y

Reviewed-by: sspitsyn, amenkov, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/24606

From kevinw at openjdk.org  Fri May 30 17:47:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 May 2025 17:47:54 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
Message-ID: <eWNYeOoALGf7BblhHMv5k1nIP-miUDxFI9JQggk3RVo=.f223cdd6-b5c7-4403-b1d7-241da832cfd8@github.com>

On Thu, 29 May 2025 10:15:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Initial commit

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 180:

> 178:     }
> 179: 
> 180:     private static void dumpThread(Thread thread, TextWriter writer) {

On the non-json text format for locks: here we're creating a new comment-like style:
// parked on ..etc...

In the regular Thread.print we always used a "-" prefix, and always printed the frame, then the relevant locks, like:

        at ThreadsMem$2.run(ThreadsMem.java:38)
        - waiting to lock <0x0000000630817da0> (a java.lang.Object)

        at java.lang.ref.ReferenceQueue.remove(java.base at 25-internal/ReferenceQueue.java:215)
        - locked <0x0000000630802350> (a java.lang.ref.ReferenceQueue$Lock)

Could we use the same?  We have a lot of history reading the established style. 8-)
Can we match the old-style "waiting to lock" rather than "waiting on" ?

I realise I'm asking to move the printing of "waiting to lock" into the loop over the stackframes, and it affects various tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116330396

From cjplummer at openjdk.org  Fri May 30 17:56:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 17:56:55 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception [v2]
In-Reply-To: <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
Message-ID: <wOtlX8UGw2822PcYNFFKojkNxLxlN3TjVrHYqA3AO30=.9010ef4d-e423-4b8f-91c3-ab0f0cfa1af4@github.com>

On Fri, 30 May 2025 03:15:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up event counters

I filed [JDK-8358172](https://bugs.openjdk.org/browse/JDK-8358172) to improve this test w.r.t. properly testing that that 2nd exception is uncaught.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25236#issuecomment-2923037831

From cjplummer at openjdk.org  Fri May 30 18:00:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 18:00:57 GMT
Subject: RFR: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception [v2]
In-Reply-To: <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
 <yNFZWoou7bKNHYtpiNeTvN7bvSYESMtfUAHyuMVfTXs=.7edf9faf-40db-42d6-b665-fcafcc20aaad@github.com>
Message-ID: <jNbtejX-vB5IsKByPMjxYeZOajHaOLWVNf841SSVwrc=.1e41542d-386a-429a-9793-1d7cf13ee9bb@github.com>

On Fri, 30 May 2025 03:15:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up event counters

Thank you for the reviews Alex, Serguei, and Leonid.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25236#issuecomment-2923043841

From cjplummer at openjdk.org  Fri May 30 18:00:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 18:00:57 GMT
Subject: Integrated: 8357184: Test
 vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java
 fails with unreported exception
In-Reply-To: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
References: <sbtOkCGQVN-QkQNasuexh_ToAlRFZ0G-SjGVhX9Sqcg=.1a33bc6c-4044-4032-9dc5-fd7bc5582b4f@github.com>
Message-ID: <1kwzBWk2ujEGL7dBgN6wfzyr3g1qBoMh0Ty_hUtH7Z0=.2b22ef2e-4ff0-4dbf-a3f4-0278b69b4699@github.com>

On Wed, 14 May 2025 18:54:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Based on the log output, the test failure seems to be the result of two threads trying to set and access variables that are not volatile, so I've made them volatile. Since I can't reproduce the failure, I can't confirm that it is now fixed, but the lack of volatile is clearly a bug so should be done anyway. Tested by running the test locally to make sure nothing breaks.

This pull request has now been integrated.

Changeset: 82807d43
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82807d43f8d18b186428be88a80ebe28892517cc
Stats:     10 lines in 1 file changed: 0 ins; 2 del; 8 mod

8357184: Test vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java fails with unreported exception

Reviewed-by: lmesnik, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25236

From alanb at openjdk.org  Fri May 30 18:18:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 18:18:59 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <eWNYeOoALGf7BblhHMv5k1nIP-miUDxFI9JQggk3RVo=.f223cdd6-b5c7-4403-b1d7-241da832cfd8@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
 <eWNYeOoALGf7BblhHMv5k1nIP-miUDxFI9JQggk3RVo=.f223cdd6-b5c7-4403-b1d7-241da832cfd8@github.com>
Message-ID: <XSomyaIAVYGD_Ogt5dQQ2TmwYXqZ2pQy41Kky2mBWeg=.9cf9f1ce-4afe-4af5-80fb-c87216273787@github.com>

On Fri, 30 May 2025 17:43:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Temp fixed until fixed in pull/25425
>>  - Sync up from loom repo, includes review comments
>>  - Merge branch 'pull/25425' into JDK-8356870
>>  - Merge branch 'pull/25425' into JDK-8356870
>>  - Initial commit
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 180:
> 
>> 178:     }
>> 179: 
>> 180:     private static void dumpThread(Thread thread, TextWriter writer) {
> 
> On the non-json text format for locks: here we're creating a new comment-like style:
> // parked on ..etc...
> 
> In the regular Thread.print we always used a "-" prefix, and always printed the frame, then the relevant locks, like:
> 
>         at ThreadsMem$2.run(ThreadsMem.java:38)
>         - waiting to lock <0x0000000630817da0> (a java.lang.Object)
> 
>         at java.lang.ref.ReferenceQueue.remove(java.base at 25-internal/ReferenceQueue.java:215)
>         - locked <0x0000000630802350> (a java.lang.ref.ReferenceQueue$Lock)
> 
> Could we use the same?  We have a lot of history reading the established style. 8-)
> Can we match the old-style "waiting to lock" rather than "waiting on" ?
> 
> I realise I'm asking to move the printing of "waiting to lock" into the loop over the stackframes, and it affects various tests.

When parked and there is a parkBlocker, blocked entering a monitor, or waiting in Object.wait, then it gets printed between the state and the stack trace. I think this is clearer. Note that the output isn't going to look at the same anyway as it's printing the object's identity hashcode rather than the address.

For the "locked" output then you may have a point, been back and forth on this. For synchronized methods then I think it's clearer when it is printed between the caller and synchronized callee. For synchronized blocks then it's clearer when to see which method has entered the monitor. Picking one means it's not clear in all cases but maybe people are just so used to "- locked" and don't notice. Can look at this again, it's trivial to swap between the two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116375673

From sspitsyn at openjdk.org  Fri May 30 18:59:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 18:59:51 GMT
Subject: RFR: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
In-Reply-To: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
References: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
Message-ID: <32ZenvVRJw1HAc9ny2csx1-zj17M8hKNTiEcoe5B-mc=.bed508a5-3c16-4db3-abab-a42ffa018dbc@github.com>

On Thu, 29 May 2025 19:14:06 GMT, Larry Cable <duke at openjdk.org> wrote:

> JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114
> 
> modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25529#pullrequestreview-2882258269

From amenkov at openjdk.org  Fri May 30 19:54:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 19:54:32 GMT
Subject: RFR: 8358202: ProblemList
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java
Message-ID: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>

The test was recently unproblem-listed and this caused a lot of noise in low tier2 of our CI

-------------

Commit messages:
 - problem list attach045

Changes: https://git.openjdk.org/jdk/pull/25555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358202
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25555/head:pull/25555

PR: https://git.openjdk.org/jdk/pull/25555

From sspitsyn at openjdk.org  Fri May 30 20:04:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 20:04:53 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
Message-ID: <BE369IARwGTX4nAleL9RLaVnLRBzLyf8AGlz9G-g3Io=.efd5a925-5931-4209-9b8b-137307b74b5e@github.com>

On Thu, 29 May 2025 10:15:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Initial commit

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 307:

> 305:         if (thread.isVirtual()) {
> 306:             jsonWriter.writeProperty("virtual", Boolean.TRUE);
> 307:         }

Q: Is the order of dumped properties important?
The JSON schema lists the `virtual` property after the `state`:

 51                         "tid": {
 52                           "type": "string",
 53                           "description": "The thread identifier."
 54                         },
 55                         "time": {
 56                           "type": "string",
 57                           "description": "The time in ISO 8601 format that the thread was sampled."
 58                         },
 59                         "name": {
 60                           "type": "string",
 61                           "description": "The thread name."
 62                         },
 63                         "state": {
 64                           "type": "string",
 65                           "description": "The thread state (Thread::getState)."
 66                         },
 67                         "virtual" : {
 68                           "type": "boolean",
 69                           "description": "true for a virtual thread."
 70                         },

The other properties dumped in the `dumpThread()` follow the order defined in JSON schema.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116554217

From sspitsyn at openjdk.org  Fri May 30 20:12:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 20:12:52 GMT
Subject: RFR: 8358202: ProblemList
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java
In-Reply-To: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
References: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
Message-ID: <aWkKywR2sVgLYah0-QbqPCwkLI2hIMGtSQmgjvDOyLk=.75a99bd9-eedf-4e75-8c9c-67cfdbe60745@github.com>

On Fri, 30 May 2025 19:45:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test was recently unproblem-listed and this caused a lot of noise in low tier2 of our CI

This is good and trivial.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25555#pullrequestreview-2882406641

From cjplummer at openjdk.org  Fri May 30 20:12:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 20:12:53 GMT
Subject: RFR: 8358202: ProblemList
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java
In-Reply-To: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
References: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
Message-ID: <yTa2bcGUf1Th_-ju_vigtKSxSJzbR-eL2Pi2WVfViCw=.562d8557-b902-410d-b230-e418b99f5b80@github.com>

On Fri, 30 May 2025 19:45:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test was recently unproblem-listed and this caused a lot of noise in low tier2 of our CI

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25555#pullrequestreview-2882409567

From cjplummer at openjdk.org  Fri May 30 20:16:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 20:16:58 GMT
Subject: RFR: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName() [v2]
In-Reply-To: <8F0yD8g0cUFrra5n4SjtfRaKQrlvnThSfvVPneltVF8=.012eb29c-c82c-4d38-91d7-37a24eaf55c4@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
 <8F0yD8g0cUFrra5n4SjtfRaKQrlvnThSfvVPneltVF8=.012eb29c-c82c-4d38-91d7-37a24eaf55c4@github.com>
Message-ID: <CLmg6jw0qsSuYgVm6TR3JfJipO0wfSWC_3WF84uhnoA=.a897fce8-1d5f-495c-8530-084e26802ff8@github.com>

On Thu, 29 May 2025 17:02:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
>> 
>> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
>> 
>> Tested nsk/jdi test locally. Will do more thorough ci testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor whitespace fix

Thank you for the reviews Leonid and Serguei!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25337#issuecomment-2923388133

From cjplummer at openjdk.org  Fri May 30 20:16:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 May 2025 20:16:59 GMT
Subject: Integrated: 8357172: Extend try block in nsk/jdi tests to capture
 exceptions thrown by Debuggee.classByName()
In-Reply-To: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
References: <golM1gtEZsP156etLBuy1zZIZPlvg2cdrW_Py5XPDL8=.4071c1d3-8f67-44a1-b206-4fb4933471ce@github.com>
Message-ID: <puBCxRjR87sCZV3cbYZUBbGN5FWNcuMdyBq8yPEoIKA=.e8a839b6-2b53-4700-ba8e-f7dcf84cbaab@github.com>

On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Extend try block to cover debuggee.classByname() call. I would suggest disabling whitespace diffs when doing the review. It makes code movement and deletions more obvious.
> 
> There are a number of places where I removed a try/catch of InterruptedException around a Thread.sleep. This will now be handled by the outer try which was moved to before this try/catch.
> 
> Tested nsk/jdi test locally. Will do more thorough ci testing.

This pull request has now been integrated.

Changeset: 14e41ab0
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14e41ab055955ffd7cf9e8129cc3269b4e3807b7
Stats:     514 lines in 22 files changed: 145 ins; 199 del; 170 mod

8357172: Extend try block in nsk/jdi tests to capture exceptions thrown by Debuggee.classByName()

Reviewed-by: lmesnik, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25337

From amenkov at openjdk.org  Fri May 30 21:03:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 21:03:03 GMT
Subject: RFR: 8358202: ProblemList
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java
In-Reply-To: <aWkKywR2sVgLYah0-QbqPCwkLI2hIMGtSQmgjvDOyLk=.75a99bd9-eedf-4e75-8c9c-67cfdbe60745@github.com>
References: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
 <aWkKywR2sVgLYah0-QbqPCwkLI2hIMGtSQmgjvDOyLk=.75a99bd9-eedf-4e75-8c9c-67cfdbe60745@github.com>
Message-ID: <xUi4QEJaeAbRANZXmhHrOVQ7anCXlChBlTGtjT_reAg=.26bba6ac-ed23-41b0-b3c0-6cfbe030aa60@github.com>

On Fri, 30 May 2025 20:08:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test was recently unproblem-listed and this caused a lot of noise in low tier2 of our CI
>
> This is good and trivial.

Thanks for the review @sspitsyn and @plummercj

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25555#issuecomment-2923469566

From amenkov at openjdk.org  Fri May 30 21:03:05 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 21:03:05 GMT
Subject: Integrated: 8358202: ProblemList
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java
In-Reply-To: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
References: <gLfvULxN6v823EFKtGOJjVrFjhfILNEo4SOpBoMA-_U=.a5fca17f-4616-4800-bbd6-06c87cf8725e@github.com>
Message-ID: <KBNhXdxyqIMRdfIkIXqyTCQOo2KRIgDDhsWhroLvVp4=.e748a292-f2b5-4c62-9933-5d4c2f3d0c4f@github.com>

On Fri, 30 May 2025 19:45:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test was recently unproblem-listed and this caused a lot of noise in low tier2 of our CI

This pull request has now been integrated.

Changeset: abbffc01
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/abbffc0103826a2e02fe52ef9b55890a57944933
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8358202: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/25555

From amenkov at openjdk.org  Fri May 30 21:14:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 21:14:58 GMT
Subject: Integrated: 8356222: Thread.print command reports waiting on the Class
 initialization monitor for both carrier and virtual threads
In-Reply-To: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
References: <HPDR1jSGqYjlCJawtb0NviAJCLE90YelW9WB3XZPDTU=.a919ffc4-6d7f-4906-9fdc-af5dd42b0e80@github.com>
Message-ID: <jiGDfZ2TuscRBs6jx9Wh-UpHcqSVIkm63vbZ-OwKMyM=.effaf04d-e2bb-4c95-b76f-beeab0384b37@github.com>

On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes "Thread.print" diagnostic command when mounted virtual thread is waiting on the class initialization monitor.
> 
> Testing: new test, tier1 sanity run

This pull request has now been integrated.

Changeset: db340e54
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db340e54f83cf7bf72abb94c9cf9cdac007ed38a
Stats:     142 lines in 4 files changed: 135 ins; 0 del; 7 mod

8356222: Thread.print command reports waiting on the Class initialization monitor for both carrier and virtual threads

Reviewed-by: alanb, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25367

From amenkov at openjdk.org  Fri May 30 21:17:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 21:17:54 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>
Message-ID: <_YErAaw444ammHxbTBhL6NuliySnPrcrsccihuCUqcA=.5afbe993-6c29-49f9-aa00-c34b63b5a9f9@github.com>

On Fri, 30 May 2025 05:29:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
>> 
>>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
>> 
>> Please, see the JVMTI ClassFileLoadHook spec:
>>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
>> 
>> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
>> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
>> 
>> Testing:
>>  - ran updated tests individually
>>  - TBD: submit mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated

test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 466:

> 464: 
> 465:     memcpy(new_arr, jni_arr, (size_t)len);
> 466:     jni->ReleaseByteArrayElements(arr, jni_arr, 0);

No need to update JNI array
Suggestion:

    jni->ReleaseByteArrayElements(arr, jni_arr, JNI_ABORT);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2116672810

From jrose at openjdk.org  Fri May 30 21:17:56 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 30 May 2025 21:17:56 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
Message-ID: <5gclUhzEQCai7QGUBDA16OcIrQcmesMGR1pJd2Hbgbw=.79a0d71a-a246-4a84-9794-43f7ef738b09@github.com>

On Fri, 30 May 2025 14:34:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More debug logs

> I like the idea of mapping each element in the table as raw bits, though handling of access to the end of the array would be a bit inconvenient (or we would have to allocate a few extra bytes).

The code snippet I shared above shows a better way:  You load a full 8 (or 4) bytes where the END (not the START) of the word lines up with the LAST (not FIRST) byte.  Then you will never run past the end of the array!  So, fine, but what about the start of the array?  Well, it's inside an `Array<u1>` object, which has a length header, which is guaranteed to be safe to load (under a cast or bytewise or whatever).  Problem solved.  The only thing to avoid is to load an 8-byte word when the packed word size is 1..5 bytes; then you load a 4-byte word.  You can load both components at once, and then use a configurable shift (from one machine word) to separate them.  This is why I say it saves a half-byte on average.

These tweaky ideas have three effects:  They probably make the code a little simpler (or at least no worse), they reduce the number of memory operations to query a packed array, and they probably use fewer ALU instructions overall.  They are certainly worth considering for the general-purpose "searchable packed array" I am envisioning; they are optional for this particular bug, viewed in isolation.

> I've changed the algorithm to use unsigned integers; in fact I find a bit annoying that most of the indices used throughout the related code are signed.

Yes, it annoys me also.  It's playing with fire (or walking the firepit).

> I've also added a test generating class with a different number of fields, though running it through the full range of fields (0-65535, though in practice the upper bound is rather 26k) would be excessive; even now it takes more than a minute on my machine. Also, I realize that varying the number of fields does not result in full coverage of possible stream sizes; per-field records have probably rather uniform lengths.

Yeah, a gtest on the binary search would cover most of those issues, faster and cleaner.  Then loading many gigantic classfiles will be unnecessary.  Just a few classfiles at several scales, probably, and thorough gtest-level unit testing, gets a better result in less time.  As I said above, I'm willing to put off some of the refactoring, given that it should cover other, prior occurrences of binary search (so it's got a larger scope than this bug).

> @rose00 OK, so I have refactored out the PackedTable that now hosts the logic for packing two uint32_t values with arbitrary number of bits into a record, and binary search using custom comparator. Haven't added any gtests to test the functionality independently, though.

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2923513912

From sspitsyn at openjdk.org  Fri May 30 22:07:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 22:07:16 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v3]
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: no need to copy array by ReleaseByteArrayElements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25422/files
  - new: https://git.openjdk.org/jdk/pull/25422/files/9f128798..086ceba4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25422&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25422&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25422/head:pull/25422

PR: https://git.openjdk.org/jdk/pull/25422

From sspitsyn at openjdk.org  Fri May 30 22:07:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 May 2025 22:07:16 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v2]
In-Reply-To: <_YErAaw444ammHxbTBhL6NuliySnPrcrsccihuCUqcA=.5afbe993-6c29-49f9-aa00-c34b63b5a9f9@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <Z7wMyKReWmrXA9N1mXrko0vL0KbQc7JVhX4IHhtAhqc=.91531e42-0a99-4e82-b60f-7323919d9e10@github.com>
 <_YErAaw444ammHxbTBhL6NuliySnPrcrsccihuCUqcA=.5afbe993-6c29-49f9-aa00-c34b63b5a9f9@github.com>
Message-ID: <wGRd6j3KWhODTZQcsKrVwZQWSmzwU-WrpSEe8kPfdIU=.14a65da0-2c17-4ba4-80e4-1308ee80687e@github.com>

On Fri, 30 May 2025 21:14:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: add a call to ReleaseByteArrayElements to new function jni_array_to_jvmti_allocated
>
> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 466:
> 
>> 464: 
>> 465:     memcpy(new_arr, jni_arr, (size_t)len);
>> 466:     jni->ReleaseByteArrayElements(arr, jni_arr, 0);
> 
> No need to update JNI array
> Suggestion:
> 
>     jni->ReleaseByteArrayElements(arr, jni_arr, JNI_ABORT);

Thanks! Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2116718682

From amenkov at openjdk.org  Fri May 30 22:36:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 May 2025 22:36:53 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v3]
In-Reply-To: <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
Message-ID: <J2a2LR0yHtAi3WpKBGDkFz4nVvO-IBQy7U4BKxzZ6YE=.5ab2540e-89c9-41f3-8636-3d8cc4e361e9@github.com>

On Fri, 30 May 2025 22:07:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
>> 
>>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
>> 
>> Please, see the JVMTI ClassFileLoadHook spec:
>>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
>> 
>> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
>> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
>> 
>> Testing:
>>  - ran updated tests individually
>>  - TBD: submit mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: no need to copy array by ReleaseByteArrayElements

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25422#pullrequestreview-2882815080

From lmesnik at openjdk.org  Fri May 30 23:24:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 May 2025 23:24:54 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v3]
In-Reply-To: <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
Message-ID: <1b8fYjEOokXjxEQrL1o4SG1jbPnKWiLSPLY1vkiUbOk=.1805f626-e4bb-4d50-822f-253c8c0e7801@github.com>

On Fri, 30 May 2025 22:07:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
>> 
>>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
>> 
>> Please, see the JVMTI ClassFileLoadHook spec:
>>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
>> 
>> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
>> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
>> 
>> Testing:
>>  - ran updated tests individually
>>  - TBD: submit mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: no need to copy array by ReleaseByteArrayElements

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25422#pullrequestreview-2882865447

From iklam at openjdk.org  Sat May 31 00:39:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 31 May 2025 00:39:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v3]
In-Reply-To: <5hyI9wOvFD_3UZWLIK4YQKcDCR0By_1SRKK2DXFPVMs=.3f2c8b3e-d0cb-41f5-a324-bcadb9cd0bad@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <fGZyNtQ44KtdcJkryezaf4jxgyFzio04DiR9tpnOGNs=.d0d49db9-b89d-4e6e-9e29-510a47995802@github.com>
 <n842vSg3v6elmkliYzRUIV_Ytwaiwm6h7MKz_x_-sMo=.4fc4901f-5496-4436-a59b-e19d48ea8959@github.com>
 <mHdOQa9Z0_U5Jr1C25BaMV84AxOnbuwOh20pnqf_9bk=.3c152471-3721-44cc-974a-246348a3d112@github.com>
 <BhqQsp-lJrKCr7f7T4VsZy5MYqLZSborSNRCb3CjYsc=.6c528213-4276-4ebd-b8a7-2ab8d9bbb3f1@github.com>
 <rCL0BZFsU5sHEbdSVeS72R3tI_oSIRRCBATvGaWZRa4=.5cce4602-2b81-4b66-be53-dc7d6ef2f8e7@github.com>
 <w0asq1nlxLZZNY7XHm8gljHEDA7vkZfysYd6dMmooJ4=.0201535a-da62-4892-a063-f6c21bbec1bf@github.com>
 <WsMN_FOtF4desMyOyLVU6Y2l06AMjBJjB_mzY8pEcV0=.3262814d-6fd1-4624-b62f-af8af14b93f8@github.com>
 <nwBD-hP6xDnLBSBRaOXEsgepX3KThDaDhhlTYyEdDtg=.1dd19a9f-1c02-44d5-926c-99308b81d96f@github.com>
 <5hyI9wOvFD_3UZWLIK4YQKcDCR0By_1SRKK2DXFPVMs=.3f2c8b3e-d0cb-41f5-a324-bcadb9cd0bad@github.com>
Message-ID: <hffMrcdBdcfDWU5TTTXk0mbTaGyE0oxi2mNiuVWDUCA=.9f7aef29-6ce0-406c-83ce-0f271a634482@github.com>

On Thu, 22 May 2025 08:18:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> To validate that you have sorted the table correctly, you should add a debug-only validation function. This function should be called after `set_fieldinfo_search_table()`, and also in `InstanceKlass::restore_unshareable_info()` and `InstanceKlass::remove_unshareable_info()`.
>
> Added, thanks for raising those places.

I suspect there's a problem with dynamic archives. I will try to write a test case to demonstrate that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2116917253

From sspitsyn at openjdk.org  Sat May 31 00:44:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 31 May 2025 00:44:57 GMT
Subject: RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001
 memory corruption when using -Xcheck:jni [v3]
In-Reply-To: <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
 <plCuTrrgLCxCzIY-ccROClPPqjO0IoEnWPPlO2s_8F8=.536d1853-c81b-4bd3-a57b-30b94363f28b@github.com>
Message-ID: <27suBErmjBpofKNNteI57Ul2fVdzNcHdHefuC18Gnqk=.2080d59d-eea6-493b-b5e7-afe1e35bd905@github.com>

On Fri, 30 May 2025 22:07:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
>> 
>>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
>> 
>> Please, see the JVMTI ClassFileLoadHook spec:
>>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
>> 
>> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
>> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
>> 
>> Testing:
>>  - ran updated tests individually
>>  - TBD: submit mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: no need to copy array by ReleaseByteArrayElements

Thank you for review, Alex and Leonid!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25422#issuecomment-2923826295

From sspitsyn at openjdk.org  Sat May 31 00:44:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 31 May 2025 00:44:58 GMT
Subject: Integrated: 8320189:
 vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001 memory corruption when
 using -Xcheck:jni
In-Reply-To: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
References: <p0q6uR1LgZ5-ToxqbXONzzpDnCVesGsYnv-s5eMXTsY=.c7710569-2aa8-41e6-95ad-01d6ec109d77@github.com>
Message-ID: <DEFM2TalhIIKoQLVZszhZA9ULNzCrtTNTLLuODf5NaU=.83562f57-1e3b-42c0-9590-5a4748b44e94@github.com>

On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file bytes with the result returned by JNI `GetByteArrayElements()`.  It violates the JVMTI `ClassFileLoadHook` spec saying:
> 
>  "The agent must allocate the space for the modified class file data buffer using the memory allocation function Allocate because the VM is responsible for freeing the new class file data buffer using Deallocate."
> 
> Please, see the JVMTI ClassFileLoadHook spec:
>    https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook
> 
> It is the root cause of a memory corruption detected with the VM option `-Xcheck:jni`.
> The fix is to convert a JNI allocated array returned by `GetByteArrayElements()` to a JMVTI allocated array. New conversion function `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`.
> 
> Testing:
>  - ran updated tests individually
>  - TBD: submit mach5 tiers 1-6

This pull request has now been integrated.

Changeset: c67fc735
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c67fc735959ddd41a8d1116908ca7bae9b966016
Stats:     48 lines in 3 files changed: 20 ins; 21 del; 7 mod

8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001 memory corruption when using -Xcheck:jni

Reviewed-by: lmesnik, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/25422

From sspitsyn at openjdk.org  Sat May 31 01:53:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 31 May 2025 01:53:50 GMT
Subject: RFR: 8358178: Some nsk/jdi tests should be run with
 includevirtualthreads=y even though they pass without
In-Reply-To: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
References: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
Message-ID: <PsikUwdioDL_j1qUJFa25Yd7vgJ03LzH3VjJpjqsJGA=.615245e7-0d7f-4a4a-b9ac-5548f1163134@github.com>

On Fri, 30 May 2025 20:56:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use -includevirtualthreads with tests use vm.allThreads() and pass with or without it. Using -includevirtualthreads gives us better virtual thread test coverage. Otherwise only the returned platform threads get tested.
> 
> Tested by running affected tests locally.

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25557#pullrequestreview-2883069548

From syan at openjdk.org  Sat May 31 03:52:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 31 May 2025 03:52:51 GMT
Subject: RFR: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
In-Reply-To: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
References: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
Message-ID: <C4I2ICm-FJ31rdbW0irPKWbvIRcofXGm4EuduE927JY=.506ba08f-2d97-4971-a14a-0ef596083c3e@github.com>

On Thu, 29 May 2025 19:14:06 GMT, Larry Cable <duke at openjdk.org> wrote:

> JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114
> 
> modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25529#pullrequestreview-2883270604

From alanb at openjdk.org  Sat May 31 06:37:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 May 2025 06:37:51 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <BE369IARwGTX4nAleL9RLaVnLRBzLyf8AGlz9G-g3Io=.efd5a925-5931-4209-9b8b-137307b74b5e@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
 <BE369IARwGTX4nAleL9RLaVnLRBzLyf8AGlz9G-g3Io=.efd5a925-5931-4209-9b8b-137307b74b5e@github.com>
Message-ID: <uVfeYVbjp2x-zZXQvnoRApc6Yg__fxajGNPd550BEJw=.b86a5437-0c2a-4fee-a4dd-073907a9d471@github.com>

On Fri, 30 May 2025 19:57:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Q: Is the order of dumped properties important?

No, the ordering doesn't matter. The intent with the schema in the API docs is that we have somewhere to describe the objects name properties. If you re-order then it still validate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2117406798

From alanb at openjdk.org  Sat May 31 08:07:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 May 2025 08:07:48 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v4]
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <gVA_dqfomf3faG6jw9gEX7TebYD78N4rEjT7aBdDyWI=.222fdc7d-0b62-42e0-9e2b-fe5ebb1b4841@github.com>

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Sync up from loom repo, includes review comments
 - Merge branch 'pull/25425' into JDK-8356870
 - Temp fixed until fixed in pull/25425
 - Sync up from loom repo, includes review comments
 - Merge branch 'pull/25425' into JDK-8356870
 - Merge branch 'pull/25425' into JDK-8356870
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25429/files
  - new: https://git.openjdk.org/jdk/pull/25429/files/04f559fb..160ca36c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25429&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25429&range=02-03

  Stats: 75 lines in 7 files changed: 31 ins; 14 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/25429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429

PR: https://git.openjdk.org/jdk/pull/25429

From mgronlun at openjdk.org  Sat May 31 10:13:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 36:

> 34: #if defined(LINUX)
> 35: 
> 36: #include "memory/padded.hpp"

What is padded? If not, this should go.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117672258

From mgronlun at openjdk.org  Sat May 31 10:13:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:13:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
 <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>
Message-ID: <BziKr0wbQDb_5pUJqeGmHkwdclyoOF1NvrYivbwxEZw=.aa000c09-133b-40a8-ad9b-a3039b755501@github.com>

On Tue, 27 May 2025 11:58:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:
>> 
>>> 172:   assert(request._sample_pc != nullptr, "invariant");
>>> 173:   assert(jt != nullptr, "invariant");
>>> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");
>> 
>> What?
>
> I also call this method for native stack traces in my implementation. As I have to walk native stack traces at stackwalks.

Assert for thread->state() == _thread_in_native then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117674370

From mgronlun at openjdk.org  Sat May 31 10:26:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:26:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:

> 361: }
> 362: 
> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {

I still don't understand what the purpose is for this routine.

I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?

It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?

In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.

This seems to be some kind of semi-solution that does not solve anything:

1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process native frames - do nothing and let the thread process everything on return from native (those native requests are still valid (the ljf is still valid).
2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117682624

From mgronlun at openjdk.org  Sat May 31 10:30:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:30:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
Message-ID: <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>

On Sat, 31 May 2025 10:22:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug printf
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:
> 
>> 361: }
>> 362: 
>> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
> 
> I still don't understand what the purpose is for this routine.
> 
> I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?
> 
> It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?
> 
> In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.
> 
> This seems to be some kind of semi-solution that does not solve anything:
> 
> 1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process native frames - do nothing and let the thread process everything on return from native (those native requests are still valid (the ljf is still valid).
> 2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.

Secondly, if you only want to process native requests that are equal to or correspond to a specific native site, you should only need to call stacktrace.record() inner for one of the sample requests, not all, and reuse the sid for all the requests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117688216

From mgronlun at openjdk.org  Sat May 31 10:43:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:43:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 139:

> 137: 
> 138:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
> 139:   static void trigger_is_thread_in_native_stackwalking();

Is it sampling that is triggered? Sampling refers to the asynchronous signal received from the OS.

You are asking for the sampler thread to process JFR Sample Requests, right? That is, already taken samples.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 263:

> 261:     // Yet another instance of safepoint bias,to be addressed with
> 262:     // more exact and stricter versions when parsable blobs become available.
> 263:     biased = true;

Careful here. This site CAN be biased, but it's also the fallthrough from the processing in 250-259, which is a direct sample hit, i.e., non-biased.

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 89:

> 87:   _has_cpu_time_jfr_requests(false),
> 88:   _cpu_time_jfr_queue(0),
> 89:   _wants_is_thread_in_native_stackwalking(false)

This field name can be improved.

"_do_async_processing_of_cpu_time_jfr_requests"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117694262
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117694730
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117693395

From jbechberger at openjdk.org  Sat May 31 13:24:59 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sat, 31 May 2025 13:24:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
 <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>
Message-ID: <1VvaCskuxVSYYFKdGKY9oUY2f2ADU31_qal8jmabmRI=.02487cd6-850e-49e9-a735-2ad257286bb4@github.com>

On Sat, 31 May 2025 10:28:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:
>> 
>>> 361: }
>>> 362: 
>>> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
>> 
>> I still don't understand what the purpose is for this routine.
>> 
>> I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?
>> 
>> It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?
>> 
>> In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.
>> 
>> This seems to be some kind of semi-solution that does not solve anything:
>> 
>> 1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process "native" sample requests - do nothing and let the thread itself process everything on return from native (those native requests are still valid (the ljf is still valid).
>> 2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.
>
> Secondly, if you only want to process native requests that are equal to or correspond to a specific native site, you should only need to call stacktrace.record() inner for one of the sample requests, not all, and reuse the sid for all the requests.

You're right, I'll be just draining the whole queue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117831282

From coleenp at openjdk.org  Sat May 31 14:52:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 31 May 2025 14:52:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
Message-ID: <UNr0VrW0ftFAlJOt7dnlb75G2NHjKctDSU_JLwixNwg=.152290e5-d819-46d1-9b6c-bbfe20375e0d@github.com>

On Fri, 30 May 2025 14:34:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More debug logs

I can reproduce the crash when building slowdebug on linux-x64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2925285454