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