From mbaesken at openjdk.org  Mon Sep  1 06:51:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:51:51 GMT
Subject: jmx-dev RFR: 8366092: [GCC static analyzer]
 UnixOperatingSystem.c warning: use of uninitialized value 'systemTicks'
 [v3]
In-Reply-To: <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
Message-ID: <bEKfrPhjDuaHSIsY8fOE7RQQnQzH23u2zsg6AoMg2F8=.d9115c81-049e-464a-809d-37795a304522@github.com>

On Fri, 29 Aug 2025 14:11:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :
>> 
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>>   208 | pticks->usedKernel = systemTicks;
>> 
>> 
>> vsscanf usually/normally reads the systemTicks info from /proc file system. see
>> https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
>> but we never check that the *exact* number of params is read with vsscanf :
>> n = vsscanf(tmp, fmt, args);
>> So potentially we could get a non complete info without systemTicks and the call would still succeed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid initialization

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26962#issuecomment-3241061930

From mbaesken at openjdk.org  Mon Sep  1 06:51:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:51:52 GMT
Subject: jmx-dev Integrated: 8366092: [GCC static analyzer]
 UnixOperatingSystem.c warning: use of uninitialized value 'systemTicks'
In-Reply-To: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
Message-ID: <TTMF7LYIf07e9_Id2jwixL1OfifmOKMTabWU-00HUos=.9c4337f2-d222-489b-9a75-cdd758eb701c@github.com>

On Wed, 27 Aug 2025 14:23:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :
> 
> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>   208 | pticks->usedKernel = systemTicks;
> 
> 
> vsscanf usually/normally reads the systemTicks info from /proc file system. see
> https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
> but we never check that the *exact* number of params is read with vsscanf :
> n = vsscanf(tmp, fmt, args);
> So potentially we could get a non complete info without systemTicks and the call would still succeed.

This pull request has now been integrated.

Changeset: a6e2a329
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6e2a329a07c71582ac696809fb5349c6a0b681c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8366092: [GCC static analyzer] UnixOperatingSystem.c warning: use of uninitialized value 'systemTicks'

Reviewed-by: kevinw, asteiner

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

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

From sroy at openjdk.org  Mon Sep  8 08:19:13 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Sep 2025 08:19:13 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <P4p8mYqMVH7obDh4bKUoyyKzdIn_vLgFWREujO4bYt8=.a5f92b4e-e9cb-4e24-84a3-0c113de1b30c@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> Who? me? Other Reviewers? Strange PR description ;-)

I edited the comment here...will edit in the bugs too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3265117328

From sroy at openjdk.org  Wed Sep 10 08:06:07 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Sep 2025 08:06:07 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <-sscVFQjjrzV4-iWqG2DIl4m7sEHC3LEB3EUQ829zQk=.0b50fc02-bf1e-4296-843d-a5cbdbf51f9b@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ProblemList.txt
>
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
> 
> Who? me? Other Reviewers? Strange PR description ;-)

Hi @tstuefe  Could you kindly review the patch with suggested changes ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3273798917

From mdonovan at openjdk.org  Wed Sep 17 11:58:25 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 17 Sep 2025 11:58:25 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use certificates
 with MD5 signatures
Message-ID: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>

This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

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

Commit messages:
 - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

Changes: https://git.openjdk.org/jdk/pull/27342/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353738
  Stats: 2551 lines in 10 files changed: 400 ins; 2046 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From kevinw at openjdk.org  Thu Sep 18 12:17:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Sep 2025 12:17:56 GMT
Subject: jmx-dev RFR: 8367983: javax/management/monitor/ThreadPoolTest.java
 and StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
Message-ID: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>

This test has failed due to a timing issue, but not continually or reproducibly.
Looks like an effect of the TIMEOUT_FACTOR change (8260555).

The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0

We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

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

Commit messages:
 - 8038950: javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!

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

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

From cjplummer at openjdk.org  Thu Sep 18 15:36:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 15:36:52 GMT
Subject: jmx-dev RFR: 8367983:
 javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail
 with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <sXZxIEqDUhJAPQomtJpUv2c7ntsK8_AVWmOnWqLjE8o=.e3a44ad0-f949-442e-9c0a-f85281509e0b@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27361#pullrequestreview-3240527778

From dholmes at openjdk.org  Fri Sep 19 04:15:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 04:15:58 GMT
Subject: jmx-dev RFR: 8367983:
 javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail
 with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <4htUvWnHZoK4GC500TSKYWWpm_1hS2RBf65RTNg03v4=.8aaf9de1-e680-4603-8b2d-0fdd00917403@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

LGTM2

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27361#pullrequestreview-3242817275

From kevinw at openjdk.org  Fri Sep 19 08:19:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Sep 2025 08:19:05 GMT
Subject: jmx-dev RFR: 8367983:
 javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail
 with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <3XNu1_EV5fIf2MV5We8GbXoegYD5SFtBCBrw8arOUBE=.18c71478-e70a-4202-8a99-b11f68736032@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27361#issuecomment-3311117973

From kevinw at openjdk.org  Fri Sep 19 08:19:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Sep 2025 08:19:06 GMT
Subject: jmx-dev Integrated: 8367983:
 javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail
 with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <m7Nu1nQiwRKvRPbQAvV12uxXzZoObdTKdQETJ5bpAF0=.046c6ca6-1c96-4908-9c1f-65e3a6710493@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.

This pull request has now been integrated.

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

8367983: javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!

Reviewed-by: cjplummer, dholmes

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

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

From sroy at openjdk.org  Tue Sep 23 16:37:58 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 23 Sep 2025 16:37:58 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <a0GFViX2wTiCHJO7yqqiXW37H2DcBUKi7JNsdbR8Jso=.f5435cea-59bf-4d62-a677-1b83905ec787@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ProblemList.txt
>
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
> 
> Who? me? Other Reviewers? Strange PR description ;-)

Hi @tstuefe  
I completely understand you?re busy. Kindly provide a review you get a chance.

Please let me know if you need any additional information from my side.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3324778210

From amenkov at openjdk.org  Tue Sep 23 20:28:59 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Sep 2025 20:28:59 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
Message-ID: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>

The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.

Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/27457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365057
  Stats: 69 lines in 6 files changed: 63 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

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

From alanb at openjdk.org  Wed Sep 24 06:33:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:33:15 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:

> 206:                 Object parkBlocker = snapshot.parkBlocker();
> 207:                 if (parkBlocker != null) {
> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)

This was `if (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allow L209 to use owner.threadId(). It also is consistent with the other use of pattern matching with instanceof in this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374569271

From dholmes at openjdk.org  Wed Sep 24 06:41:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Sep 2025 06:41:15 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:

> 50: 
> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
> 52:     private Thread parkBlockerOwner;

Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374595923

From alanb at openjdk.org  Wed Sep 24 06:41:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:41:17 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <YhKAzx3Cb7oPMgpybD50CIu2zxCBEm71Fsg4Oo5ID0g=.fffb9b8e-a4bf-4a6a-9e78-c3ce82858ec3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:

> 693:     }
> 694: 
> 695:     /**

In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374587163

From alanb at openjdk.org  Wed Sep 24 07:07:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 07:07:17 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
Message-ID: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>

On Wed, 24 Sep 2025 06:38:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
> 
>> 50: 
>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>> 52:     private Thread parkBlockerOwner;
> 
> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374672607

From amenkov at openjdk.org  Wed Sep 24 19:59:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 19:59:55 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/b0425b68..5a2a8dc7

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

  Stats: 19 lines in 3 files changed: 5 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

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

From amenkov at openjdk.org  Wed Sep 24 20:04:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:32 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
Message-ID: <avSCzUEBJ8P33fqLCvkZ2xhW_Nh3f7DmOjA4eeBvK3s=.de4371a3-0bcc-473b-8a47-7e22e7137967@github.com>

On Wed, 24 Sep 2025 06:30:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:
> 
>> 206:                 Object parkBlocker = snapshot.parkBlocker();
>> 207:                 if (parkBlocker != null) {
>> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)
> 
> This was `String suffix = (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allows L209 to use owner.threadId(). I think I'd prefer it here as it makes it consistent with the other uses of pattern matching with instanceof in this code.

Fixed (and for json version too)

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:
> 
>> 693:     }
>> 694: 
>> 695:     /**
> 
> In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925109
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376926531

From amenkov at openjdk.org  Wed Sep 24 20:04:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:34 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
 <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
Message-ID: <D8IghIMuy52RLYS8IWTSljAXxKR5rqvIYtM8RBuMv1c=.3bd5aef4-4528-4946-b080-fdf8fc245913@github.com>

On Wed, 24 Sep 2025 07:04:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
>> 
>>> 50: 
>>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>>> 52:     private Thread parkBlockerOwner;
>> 
>> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?
>
> The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925797

From sspitsyn at openjdk.org  Thu Sep 25 01:42:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 01:42:48 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377441081

From dholmes at openjdk.org  Thu Sep 25 02:06:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:29 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Looks good.

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:

> 81:                           "owner": {
> 82:                             "type": "string",
> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."

Is it possible for there to not be an owner? If so what does this report?

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 696:

> 694: 
> 695:     /**
> 696:      * Finds the line of plain text thread dump containing the given text.

Suggestion:

     * Finds the line of a plain text thread dump containing the given text.

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

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3265266068
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377469785
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472831

From dholmes at openjdk.org  Thu Sep 25 02:06:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:31 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
Message-ID: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>

On Thu, 25 Sep 2025 01:40:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

The original "contain" was correct. Alternatively:
> Returns true if lines is a plain text thread dump containing the given text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472427

From stuefe at openjdk.org  Thu Sep 25 06:12:30 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Sep 2025 06:12:30 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v6]
In-Reply-To: <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
Message-ID: <t7sUStz5mQ-yJeIdXkGCECfCdEyBh4PA_Q8FGKhtR8c=.04f5c602-aa8e-4caf-a05b-e43e3a963ab3@github.com>

On Fri, 29 Aug 2025 08:56:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313

@JoKern65 could you take a look at this and possibly give a review?

@suchismith1993 Sorry, I'm busy and will be gone starting next week for most of October. Maybe Joachim and @MBaesken or @TheRealMDoerr can help. If they approve, I am fine with their reviews.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3332322591

From alanb at openjdk.org  Thu Sep 25 06:32:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:32:31 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
Message-ID: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>

On Thu, 25 Sep 2025 01:59:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
> 
>> 81:                           "owner": {
>> 82:                             "type": "string",
>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
> 
> Is it possible for there to not be an owner? If so what does this report?

In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377894888

From alanb at openjdk.org  Thu Sep 25 06:36:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:36:48 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <cIjt_YSfVx-OGTkQwCrj1Hn9HzGcfRknNXxUP4lyWpA=.61e50aa3-7481-4c30-be69-0bf70df76a46@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:

> 85:                           "required": [
> 86:                             "object"
> 87:                           ]

At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377903090

From alanb at openjdk.org  Thu Sep 25 06:50:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:50:01 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <oxZPKpXQMZm38uh-MplGAT_FK-eQhc1Tjf8fV10KDhs=.b20c0974-b2ed-4a5a-8dd4-513db8f4693e@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:

> 443:             assertNotNull(parkBlocker);
> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
> 445: 

Will you add 8365057 to the `@bug` at the top?

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:

> 298: 
> 299:         /**
> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.

Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377924570
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377928658

From alanb at openjdk.org  Thu Sep 25 07:08:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 07:08:03 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:

> 45:     private int blockerTypeOrdinal;
> 46:     private Object blockerObject;
> 47:     // the owner of the blockerObject when the object is park blocker and is AQS

Typo here, AQS != AbstractOwnableSynchronizer

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377970208

From jkern at openjdk.org  Thu Sep 25 09:17:09 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 25 Sep 2025 09:17:09 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v6]
In-Reply-To: <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
Message-ID: <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>

On Fri, 29 Aug 2025 08:56:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 134:

> 132:             cpu_load = MAX(cpu_load, 0.0);
> 133:             cpu_load = MIN(cpu_load, 1.0);
> 134:             cpu_load = (user_diff + sys_diff) / delta_time;

Why is the sequence here different to the sequence in Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2378377387

From duke at openjdk.org  Thu Sep 25 12:44:33 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 12:44:33 GMT
Subject: jmx-dev RFR: 8360498: [TEST_BUG] Some Mixing test continue to
 fail [v15]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <LbtKjOFGsHTibAzEPUiW9ZqBktChIHNCRguabF9NWAA=.d17d091e-79d8-40eb-b320-cd36aac1503c@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'openjdk:master' into jdk-8360498
 - Removes not needed changes
 - Revert "Removes not needed changes"
   
   This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
 - Removes not needed changes
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14
  Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Thu Sep 25 13:03:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 13:03:51 GMT
Subject: jmx-dev RFR: 8360498: [TEST_BUG] Some Mixing test continue to
 fail [v16]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Resolves confict for when there is a merge with jdk-8158801

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15

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

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

From alanb at openjdk.org  Thu Sep 25 13:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 13:30:34 GMT
Subject: jmx-dev RFR: 8360498: [TEST_BUG] Some Mixing test continue to
 fail [v16]
In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
Message-ID: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>

On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolves confict for when there is a merge with jdk-8158801

What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893

From duke at openjdk.org  Thu Sep 25 14:00:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:08 GMT
Subject: jmx-dev RFR: 8360498: [TEST_BUG] Some Mixing test continue to
 fail [v17]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <IFBetIfNildsjk1H900soCAiLg2EM8nsjrkfKOPWBV4=.4ccfcb8f-ec0e-4c6b-a713-c604c6a9f114@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8360498
 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling
   
   Reviewed-by: aph, rcastanedalo
 - 8367103: RISC-V: store cpu features in a bitmap
   
   Reviewed-by: fyang, luhenry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16

  Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Thu Sep 25 14:00:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:10 GMT
Subject: jmx-dev RFR: 8360498: [TEST_BUG] Some Mixing test continue to
 fail [v16]
In-Reply-To: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
 <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
Message-ID: <URXFmVJhmSe8PBZ4Vdbqw_lKQyw9TfofauV5j6QYwzA=.50d49205-a08a-4147-a97e-66f090371efc@github.com>

On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Resolves confict for when there is a merge with jdk-8158801
>
> What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

@AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324

From sroy at openjdk.org  Thu Sep 25 14:35:51 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 25 Sep 2025 14:35:51 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v7]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Update UnixOperatingSystem.c
  
  change sequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/46dcf313..55520100

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

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

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

From sroy at openjdk.org  Thu Sep 25 14:35:56 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 25 Sep 2025 14:35:56 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v6]
In-Reply-To: <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
 <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>
Message-ID: <S115Bddcjzcpy3eHxa5_UeaQoRMoZRD9wTK0aTXY4i0=.0e5a765b-10a5-41fa-a6e2-bb696eb7e549@github.com>

On Thu, 25 Sep 2025 09:13:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - Thread safety,struct and perfInit()
>>  - Thread safety,struct and perfInit()
>>  - Update ProblemList.txt
>>  - Merge branch 'master' into cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - cleanup
>>  - system cpu load
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313
>
> src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 134:
> 
>> 132:             cpu_load = MAX(cpu_load, 0.0);
>> 133:             cpu_load = MIN(cpu_load, 1.0);
>> 134:             cpu_load = (user_diff + sys_diff) / delta_time;
> 
> Why is the sequence here different to the sequence in Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0 ?

Thanks for catching this. Missed this detail for this method. Had kept the right logic in other one.  It does not get caught in the tests either!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2379374478

From amenkov at openjdk.org  Thu Sep 25 19:09:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:09:13 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v3]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <hmSQ8IzFdvbQzL070v_Y7ojzcRrMqzZty-mljypBNUQ=.da582904-f7a3-4e58-923e-aaa8a71b2ace@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/5a2a8dc7..e8715cc2

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

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

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

From amenkov at openjdk.org  Thu Sep 25 19:33:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:33:58 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v4]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <CuCEjfyczTqDMlXZFRrWd2ZUxdToVbPUO4IYJfOmFYc=.a3ec45fb-48f7-400f-9a34-4e61909112d0@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/e8715cc2..fb3d55ad

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

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

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

From amenkov at openjdk.org  Thu Sep 25 19:34:00 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:00 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
 <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
Message-ID: <6He4wm7RD2rsTwbL7449BhfGf2NxMrENHUhuZRr-qcQ=.b5eb75e1-7aa6-435c-9879-da935198baca@github.com>

On Thu, 25 Sep 2025 06:29:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
>> 
>>> 81:                           "owner": {
>>> 82:                             "type": "string",
>>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
>> 
>> Is it possible for there to not be an owner? If so what does this report?
>
> In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

Yes, owner may be absent.
As we discussed in the JBS, owner can release the object at any time (and set "parkBlockerOwner" field to null)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380094231

From amenkov at openjdk.org  Thu Sep 25 19:34:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:02 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
Message-ID: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>

On Thu, 25 Sep 2025 02:02:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
>> 
>>> 686: 
>>> 687:     /**
>>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
>> 
>> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?
>
> The original "contain" was correct. Alternatively:
>> Returns true if lines is a plain text thread dump containing the given text.

Well.. this was Alan's request to update the comment.
To me original comment was clear and correct.
@AlanBateman , what do you prefer to see here:
- Returns true if lines of a plain text thread dump contain the given text. (original)
- Returns true if lines of a plain text thread dump is containing the given text.
- Returns true if lines is a plain text thread dump containing the given text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380081779

From amenkov at openjdk.org  Thu Sep 25 19:40:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:40 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/fb3d55ad..bc664ef4

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

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

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

From amenkov at openjdk.org  Thu Sep 25 19:40:45 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:45 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
Message-ID: <Zax25QuffcAFRfr0gJoz8Lzu3SrZ_4YGEFPbuZ2dpK4=.a4676372-e401-4198-a3da-e77bee4f0fa2@github.com>

On Thu, 25 Sep 2025 07:05:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:
> 
>> 45:     private int blockerTypeOrdinal;
>> 46:     private Object blockerObject;
>> 47:     // the owner of the blockerObject when the object is park blocker and is AQS
> 
> Typo here, AQS != AbstractOwnableSynchronizer

Replaced with "AbstractOwnableSynchronizer"

> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:
> 
>> 85:                           "required": [
>> 86:                             "object"
>> 87:                           ]
> 
> At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

Fixed

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:
> 
>> 443:             assertNotNull(parkBlocker);
>> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
>> 445: 
> 
> Will you add 8365057 to the `@bug` at the top?

Done

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:
> 
>> 298: 
>> 299:         /**
>> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.
> 
> Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380140551
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139086
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139344
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139864

From alanb at openjdk.org  Fri Sep 26 06:01:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:01:19 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
 <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
Message-ID: <4XBBUGAlktyMI3A2agyrCjlY4IKtxp1eUX8_YWSp_gI=.f9f1e32b-1a3c-4265-bafb-767211e171b5@github.com>

On Thu, 25 Sep 2025 19:08:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The original "contain" was correct. Alternatively:
>>> Returns true if lines is a plain text thread dump containing the given text.
>
> Well.. this was Alan's request to update the comment.
> To me original comment was clear and correct.
> @AlanBateman , what do you prefer to see here:
> - Returns true if lines of a plain text thread dump contain the given text. (original)
> - Returns true if lines of a plain text thread dump is containing the given text.
> - Returns true if lines is a plain text thread dump containing the given text.

Apologies, it was a typo in a separate branch used for prototype. So ignore my comment, I think left the existing comment on the test method as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380945985

From alanb at openjdk.org  Fri Sep 26 06:31:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:31:15 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <99K6laRc0VAmj4SpVQUMyFFqGNa2pRr3s-b6atp8jzE=.fd9bb67e-5902-4bfc-aef5-2e8b9c256581@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Aside from the issues with the method comments in the DumpThreads test, I think this is okay and I don't have other comments.

As per the discussion in the JBS issue, it's still a bit icky to read this field when all access is plain access, but it may be useful for diagnosing hangs and deadlocks.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270352643

From sspitsyn at openjdk.org  Fri Sep 26 07:24:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:24:26 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Just one simple comment update is still needed. Otherwise, it is good.

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: This still needs to be reverted back.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270528351
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2381135179

From amenkov at openjdk.org  Fri Sep 26 19:05:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:32 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  reverted comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/bc664ef4..f588a6da

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

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

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

From sspitsyn at openjdk.org  Fri Sep 26 19:19:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 19:19:24 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
Message-ID: <etXxraj3IIaQ0VLwwgB2u-uGCGFfopkpjrR7hQz6lgQ=.e18358d0-5f8a-447b-9ec5-716ee2d1898b@github.com>

On Fri, 26 Sep 2025 19:05:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3273600528

From amenkov at openjdk.org  Fri Sep 26 19:05:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:35 GMT
Subject: jmx-dev RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
 <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
Message-ID: <PipknE4_c6ETRhMkBPMxUhl3braANS3e4xPFDpAv8DQ=.91df2314-f53f-4600-bc54-5f0f4e31a773@github.com>

On Fri, 26 Sep 2025 07:20:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: This still needs to be reverted back.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2383242806

From amenkov at openjdk.org  Fri Sep 26 20:52:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 20:52:40 GMT
Subject: jmx-dev Integrated: 8365057: Add support for java.util.concurrent
 lock information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <QjOZIt0Ydlb7DmgAItQeuf83Q9aOzUqgELPHvciMr44=.b577ef3a-2f60-4444-8600-d1d5025cb542@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: cedc0117
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cedc0117ac36243cc240e8ab6adb3c78af4055fc
Stats:     78 lines in 6 files changed: 65 ins; 0 del; 13 mod

8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file

Co-authored-by: Alex Menkov <amenkov at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: sspitsyn, alanb

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

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

From duke at openjdk.org  Sat Sep 27 17:04:33 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sat, 27 Sep 2025 17:04:33 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU
 time
Message-ID: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>

Hi all,

This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.

`CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.

FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.

Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

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

Commit messages:
 - Remove extra new line
 - Add GC CPU MXBeans

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

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

From alanb at openjdk.org  Sat Sep 27 17:04:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Sep 2025 17:04:33 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341792562

From duke at openjdk.org  Sat Sep 27 17:04:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sat, 27 Sep 2025 17:04:34 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>
Message-ID: <Br_jY1jQZCwL7kw3X6mV7HxLRpbCT6eOYEH_95oDPzI=.6fb44cbc-3a02-465d-af0d-9d15e7fbce21@github.com>

On Sat, 27 Sep 2025 14:13:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this.

Thanks @AlanBateman. I did first consider `GarbageCollectorMXBean` but given that this interface only exposes a sub-component of the GC at a time it might not fit in well with a systemic method that samples the total GC CPU time.

To clarify what I mean with "exposing a sub-component at a time"; consider the following

List<GarbageCollectorMXBean> list = java.lang.management.ManagementFactory.getGarbageCollectorMXBeans();
for (GarbageCollectorMXBean gcMXBean : list) {
     System.out.println(gcMXBean.getName());
}

Its output will be

$ java -XX:+UseSerialGC Main.java
Copy
MarkSweepCompact

$ java -XX:+UseParallelGC Main.java
PS MarkSweep
PS Scavenge

 java -XX:+UseG1GC Main.java
G1 Young Generation
G1 Concurrent GC
G1 Old Generation

$ java -XX:+UseZGC Main.java
ZGC Minor Cycles
ZGC Minor Pauses
ZGC Major Cycles
ZGC Major Pauses


So no `GarbageCollectorMXBean` for any collector would map nicely to a systemic method like `getGcCpuTime()`. I could be wrong but I don't think there will be many use cases where a user wants/needs to know CPU time per each GC component nor does we currently support such granularity. If we look at the API for `MemoryMXBean` (https://docs.oracle.com/en/java/javase/25/docs/api/java.management/java/lang/management/MemoryMXBean.html) we can se that it do already include a couple of methods to query a "systemic property":

* `getHeapMemoryUsage()`
* `getNonHeapMemoryUsage()`

Additionally it includes a method to request a GC, which made me think that this could be a good fit for this method. That being said if my above observations are incorrect or there is a more appropriate place to put this method I'm happy to update the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341917745

From dholmes at openjdk.org  Mon Sep 29 01:36:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Sep 2025 01:36:22 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3344548511

From myankelevich at openjdk.org  Mon Sep 29 10:28:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 29 Sep 2025 10:28:19 GMT
Subject: jmx-dev RFR: 8365072: Refactor tests to use PEM API (Phase 2)
 [v3]
In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
Message-ID: <iWr9NfPTK1SgsC0M8bFlnv0tRvIeCPI4P_X9J_ddrHo=.685f585d-dcad-4c49-b3e8-5884faeeb05f@github.com>

> Tests changed in this PR: 
> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
> 12. test/jdk/sun/security/rsa/InvalidBitString.java
> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
> 
> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)

Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision:

 - removed pemrecord usage
 - 8365190: Remove LockingMode related code from share
   
   Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo
 - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp
   
   Reviewed-by: aboldtch, tschatzl, jwaters
 - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement
   
   Reviewed-by: dlong, mdoerr
 - 8366864: Sort os/linux includes
   
   Reviewed-by: ayang, dholmes
 - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages
   
   Reviewed-by: ayang, shade, stefank, tschatzl
 - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR)
   
   Reviewed-by: vromero
 - 8365776: Convert JShell tests to use JUnit instead of TestNG
   
   Reviewed-by: vromero
 - 8354871: Replace stack map frame type magics with constants
   
   Reviewed-by: liach
 - 8361533: Apply java.io.Serial annotations in java.logging
   
   Reviewed-by: rriggs
 - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27194/files
  - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa

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

  Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod
  Patch: https://git.openjdk.org/jdk/pull/27194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194

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

From kevinw at openjdk.org  Mon Sep 29 12:08:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Sep 2025 12:08:14 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <aFPbqgoyuZLZ5uGG1vSnmKd3XVEwUwkEq2B-oIgKrx0=.55a507d5-aa05-4d20-a35d-4b5f985a0b2b@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

src/hotspot/share/include/jmm.h line 85:

> 83:   JMM_GC_COUNT                       = 10,   /* Total number of collections */
> 84:   JMM_GC_CPU_TIME                    = 11,   /* Total accumulated GC CPU time */
> 85:   JMM_JVM_UPTIME_MS                  = 12,   /* The JVM uptime in milliseconds */

It looks a bit odd to me to change the existing define of UPTIME here.  
OK it is not a public interface used between different versions, and people should not be mixing up jmm.h and management implementations...  But usually we would just add the new definition? (items below are not strictly grouped by name)  Maybe this is just a nit, and only makes cross-version comparisons easier.

Looks good overall.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2387698942

From duke at openjdk.org  Tue Sep 30 04:38:48 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 04:38:48 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Thanks, it?s a useful function. (I would not have expected it in the memory bean but in the go bean, but I guess both is fine.) Some more comments inline

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273:

> 271:      * Returns the CPU time used by all garbage collection threads.
> 272:      *
> 273:      * <p> This include time since genesis, so the value can be

The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.??

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:

> 277:      * deduplication thread (if enabled). This method returns
> 278:      * {@code -1} if the platform does not support this operation
> 279:      * or if called during shutdown.

Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:

> 280:      *
> 281:      * @return the total CPU time for all garbage collection
> 282:      * threads in nanoseconds.

Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?

test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73:

> 71:                 while (true) {
> 72:                     long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime();
> 73:                     if (gcCpuTimeFromThread < -1) {

None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported?

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

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3282521865
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389806062
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389808338
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389815933
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389822026

From duke at openjdk.org  Tue Sep 30 09:02:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:02:39 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>

On Tue, 30 Sep 2025 04:29:40 GMT, Bernd <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:
> 
>> 280:      *
>> 281:      * @return the total CPU time for all garbage collection
>> 282:      * threads in nanoseconds.
> 
> Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?

It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds.

> test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73:
> 
>> 71:                 while (true) {
>> 72:                     long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime();
>> 73:                     if (gcCpuTimeFromThread < -1) {
> 
> None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported?

The reason why there is no test for that is because `-1` is a valid return value. If this test is run on a system that does not support CPU time from os or if it queried during shutdown when we are terminating threads we opt to return `-1` for safety reasons. We cannot assume that OpenJDK is never run on a platform that does not support certain optional `os` implementations.

The goal with this test is to verify the shutdown protection and the API. Additionally, since this API is piggybacking on other methods (effectively in `os`) that are actually responsible for the CPU time functionality, I believe they would be responsible implement tests for what you suggest.

FWIW; I had a quick look and the tests that you are expecting might already be found in e.g. `test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadMonitor.java`, `vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/TestDescription.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390416360
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390406537

From duke at openjdk.org  Tue Sep 30 09:11:49 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:11:49 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>

On Tue, 30 Sep 2025 04:21:44 GMT, Bernd <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273:
> 
>> 271:      * Returns the CPU time used by all garbage collection threads.
>> 272:      *
>> 273:      * <p> This include time since genesis, so the value can be
> 
> The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.??

Thanks @ecki for pointing that out :) I make a simplification whenever the CSR discussion (https://bugs.openjdk.org/browse/JDK-8368529) have reached a consensus where this method should live.

> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:
> 
>> 277:      * deduplication thread (if enabled). This method returns
>> 278:      * {@code -1} if the platform does not support this operation
>> 279:      * or if called during shutdown.
> 
> Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?

Just want to ensure that I read this correct, please correct any mistake below:

* concurrent time = `CPU time`
* accumulate times = `wall-clock time`

Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390466153
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390453810

From duke at openjdk.org  Tue Sep 30 09:18:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:18:12 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <leYHhsAOI1HJEGUhPdBCK3ww2ficj5fJoUFTxAa8Dnk=.3dfdb3ef-1508-46c0-8fba-1dae6bdb70e1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Thanks @kevinjwalls for your review. I will update the order in `jmm.h` whenever we have reached a consensus in the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350875133

From duke at openjdk.org  Tue Sep 30 09:22:18 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:22:18 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <FVVak25Et_CRvOJRToV6PJf5l-mrjEYWZo0KVm9H3hc=.c908c72d-e74d-41c4-bf87-4ef1943eaba4@github.com>

On Tue, 30 Sep 2025 04:35:46 GMT, Bernd <duke at openjdk.org> wrote:

> Thanks, it?s a useful function

@ecki That's great to hear ?! Thanks for taking your time to go through this and provide feedback/comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350891366

From duke at openjdk.org  Tue Sep 30 09:22:20 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 09:22:20 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
Message-ID: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>

On Tue, 30 Sep 2025 09:06:48 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:
>> 
>>> 277:      * deduplication thread (if enabled). This method returns
>>> 278:      * {@code -1} if the platform does not support this operation
>>> 279:      * or if called during shutdown.
>> 
>> Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?
>
> Just want to ensure that I read this correct, please correct any mistake below:
> 
> * concurrent time = `CPU time`
> * accumulate times = `wall-clock time`
> 
> Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?

It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390505263

From duke at openjdk.org  Tue Sep 30 09:28:25 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:28:25 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
Message-ID: <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>

On Tue, 30 Sep 2025 09:19:28 GMT, Bernd <duke at openjdk.org> wrote:

>> Just want to ensure that I read this correct, please correct any mistake below:
>> 
>> * concurrent time = `CPU time`
>> * accumulate times = `wall-clock time`
>> 
>> Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?
>
> It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?

In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390533951

From duke at openjdk.org  Tue Sep 30 09:41:26 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 09:41:26 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>
Message-ID: <c6PwyV6Nu91uRUPEI5Gk3jnfI5IlhpLtp3OO0rk3Lc8=.56ff6be9-5eba-4b32-afed-6d3a19a6a6b9@github.com>

On Tue, 30 Sep 2025 08:58:54 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:
>> 
>>> 280:      *
>>> 281:      * @return the total CPU time for all garbage collection
>>> 282:      * threads in nanoseconds.
>> 
>> Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?
>
> It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds.

It?s in Both names - especially with the Description - understandable what it means, I was just afraid that people could confuse concepts. Maybe it doesn?t really matter. I think in the gc specific ones the colateral doc was a bit more specific about concurrent times and pauses, in the past.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390586886

From alanb at openjdk.org  Tue Sep 30 10:45:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Sep 2025 10:45:15 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
Message-ID: <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>

On Mon, 29 Sep 2025 01:33:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request

The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed.

It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific.

If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351299156

From kevinw at openjdk.org  Tue Sep 30 10:48:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 30 Sep 2025 10:48:00 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
Message-ID: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>

On Tue, 30 Sep 2025 09:25:24 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?
>
> In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?

Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
"
Returns the CPU time used by all garbage collection threads.

This includes time for all driver threads, workers, VM operations
on the VM thread, and the string deduplication thread (if enabled). 
Therefore the value can be non-zero even if no garbage collection cycles have occurred. 

This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390853215

From duke at openjdk.org  Tue Sep 30 11:25:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 11:25:53 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
Message-ID: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>

On Tue, 30 Sep 2025 10:41:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request
>
>> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request
> 
> The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed.
> 
> It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific.
> 
> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

@AlanBateman

> The CSR is probably a bit premature ...

Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?

> Right now, the draft API spec makes it sounds very HotSpot VM specific.

Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?

> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351513274

From duke at openjdk.org  Tue Sep 30 11:44:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 11:44:43 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
 <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
Message-ID: <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>

On Tue, 30 Sep 2025 10:45:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?
>
> Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
> "
> Returns the CPU time used by all garbage collection threads.
> 
> This includes time for all driver threads, workers, VM operations
> on the VM thread, and the string deduplication thread (if enabled). 
> Therefore the value can be non-zero even if no garbage collection cycles have occurred. 
> 
> This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
> "

I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391079350

From kevinw at openjdk.org  Tue Sep 30 11:53:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 30 Sep 2025 11:53:23 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
 <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
 <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>
Message-ID: <A1NxElV-BuPWjHZJR50mklz-6mezEuEVfGdXjAH9oR4=.d10d7c85-593a-4b81-ad74-5dec10332666@github.com>

On Tue, 30 Sep 2025 11:41:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
>> "
>> Returns the CPU time used by all garbage collection threads.
>> 
>> This includes time for all driver threads, workers, VM operations
>> on the VM thread, and the string deduplication thread (if enabled). 
>> Therefore the value can be non-zero even if no garbage collection cycles have occurred. 
>> 
>> This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
>> "
>
> I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here?

"CPU time used by all garbage collection threads"  or even "Accumulated CPU time..." would seem clear that we mean these threads, in this process.  We can leave genesis out of it, whether it meant start of process or dawn of time. 8-)

Yes, might be better as just, "This may include some startup work and overhead, therefore the value can be non-zero even...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391101498