From dfuchs at openjdk.org  Tue Jul  1 07:35:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Jul 2025 07:35:40 GMT
Subject: jmx-dev RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <vNNZnSq-ruFJlo34wwSVX03EzhaGd4p0h0XA2fpgsZ4=.8a4d40cc-7043-460c-8576-d9dabdcdb4b4@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

The changes look reasonable. Please get a Reviewer from serviceability too before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2973919189

From kevinw at openjdk.org  Tue Jul  1 08:52:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 08:52:56 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Further doc update
 - Test udpate (listIterator)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/8b36d3e5..a2a28dde

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

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

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

From sspitsyn at openjdk.org  Tue Jul  1 10:15:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 10:15:42 GMT
Subject: jmx-dev RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <5KWnC8pnEXr4Vo_kL09Zn6fvR5AeszMX2APiogVLwmQ=.3902890e-16aa-4430-b252-3a2978fcfe42@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

This looks okay.
The CSR's "Compatibility Risk Description" should not be empty.
Also reviewed the RN and added a minor suggestion.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2974681915

From kevinw at openjdk.org  Tue Jul  1 10:37:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 10:37:38 GMT
Subject: jmx-dev RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <fg_eY5yPM8Z0irGghVrhs6LBniJ-jDuCQ7e2aliO4kg=.94a46470-9f72-4bf4-a787-1ff18c1c4ac9@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

Thanks Daniel!  Thanks Serguei, have addressed those points.

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

PR Comment: https://git.openjdk.org/jdk/pull/25697#issuecomment-3023296826

From kevinw at openjdk.org  Wed Jul  2 09:04:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 09:04:51 GMT
Subject: jmx-dev [jdk25] RFR: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
Message-ID: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>

Clean backport to JDK 25.

This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

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

Commit messages:
 - Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16

Changes: https://git.openjdk.org/jdk/pull/26088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359870
  Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26088/head:pull/26088

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

From rrich at openjdk.org  Wed Jul  2 09:36:15 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 2 Jul 2025 09:36:15 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java
 fails because of unstable inlining
Message-ID: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>

This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.

Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.

Testing: x86_64, ppc64

Failed inlining on x86_64 with TieredCompilation disabled:


make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1

[...]

STDOUT:
CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
                            @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
                            @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
                              @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
                                @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
                            @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
              s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
              s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
              s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
                              @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
                            @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
2025-07-02T09:25:53.396634900Z Attempt 1, found: false
2025-07-02T09:25:53.415673072Z Attempt 2, found: false
2025-07-02T09:25:53.418876867Z Attempt 3, found: false

[...]

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

Commit messages:
 - Force inlining of String*.* methods
 - Force inlining of StringBuffer methods

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

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

From rrich at openjdk.org  Wed Jul  2 09:36:15 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 2 Jul 2025 09:36:15 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <owf286wT2T5xGJQ1QoqEACi9Q209c9Xpv2SJZSqs3jo=.1193694c-58ca-4e9d-a842-29b76778a30a@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Jit compiler folks might want to have a look at this pr. Maybe there's a better for having the StringBuilder locks eliminated deterministically.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3027054192

From mdoerr at openjdk.org  Wed Jul  2 09:54:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 09:54:41 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <TJiYFA8CQv-efB9QVsjMu-Ehn7t6uup4LFjlFgXqpCQ=.012942f6-8e5a-4ed2-9f29-f44ad1291780@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2978510981

From alanb at openjdk.org  Thu Jul  3 08:39:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 08:39:40 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Thanks for improving this, this test was intended unstable. 

It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2982264097

From rrich at openjdk.org  Thu Jul  3 14:38:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 3 Jul 2025 14:38:40 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
Message-ID: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>

On Thu, 3 Jul 2025 08:36:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out.

I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3032511575

From lmesnik at openjdk.org  Thu Jul  3 16:59:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 3 Jul 2025 16:59:40 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <DCsthNw-6hib-dyg2Tz_TzLP-Iz-MQBbit_7fCC6fMs=.dfe8fb45-04d7-4ecf-9b30-15a1f4e4b424@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2983913131

From alanb at openjdk.org  Thu Jul  3 17:59:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 17:59:44 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
Message-ID: <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>

On Thu, 3 Jul 2025 14:36:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.

I think that would be useful, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3033099720

From rrich at openjdk.org  Fri Jul  4 08:14:19 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 4 Jul 2025 08:14:19 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Allow vm.debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26033/files
  - new: https://git.openjdk.org/jdk/pull/26033/files/8561d522..a43e54db

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

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

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

From rrich at openjdk.org  Fri Jul  4 08:14:20 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 4 Jul 2025 08:14:20 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
 <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
Message-ID: <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>

On Thu, 3 Jul 2025 17:57:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.
> 
> I think that would be useful, thank you.

I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3034923279

From alanb at openjdk.org  Fri Jul  4 10:27:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Jul 2025 10:27:39 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <Hqr-Ryjr-xHnn_pnhTmRhhbvvq59jibwJ3bVAbQE26w=.d7560c4e-ac9f-495a-80cc-cc19aeb29197@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2986518539

From kevinw at openjdk.org  Fri Jul  4 12:18:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 4 Jul 2025 12:18:42 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <K35liKJ1R-7bN63VnQjPbKOGjJbmAkXzAVIteXjNv10=.bbae3a6a-2610-4082-b88d-13973b43b5e7@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

About the test and debug mode, we had that kind of conversation in https://github.com/openjdk/jdk/pull/25958
Windows and Macosx were likely to timeout in debug builds, Linux was OK for me.  Not sure if the inlining requests here affect that much, will be interesting to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3035981114

From rrich at openjdk.org  Mon Jul  7 07:44:39 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 07:44:39 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <aBNFHmMzCn1WfT1rlxSCLBegorJV-tSCFvJsjnorB34=.5fd6a0e7-52c5-4c0c-bd0f-e5d07ae865fb@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

> About the test and debug mode, we had that kind of conversation in #25958 Windows and Macosx were likely to timeout in debug builds, Linux was OK for me. Not sure if the inlining requests here affect that much, will be interesting to see.

You got timeouts likely because the test searched for eliminated locking in the thread dumps in an endless loop but lock elimination has failed (very early) due to unfavorable inlining.

Inlining depends on timing because jit compilation runs asynchronously in the background. It affects inlining if a call target is already compiled into a big nmethod (see `failed to inline: already compiled into a big method` above). Calls critical for lock elimination will still be inlined because of the `CompileCommand` inlining requests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043813314

From rrich at openjdk.org  Mon Jul  7 07:44:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 07:44:40 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
 <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
 <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>
Message-ID: <tjJT49xXHwBZsmm1yq83Q2JUrkgCXQZ25hB_k9kDeFU=.ed3db8bc-8d64-42bd-bfd4-3956b83ba6b6@github.com>

On Fri, 4 Jul 2025 08:11:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms.

Local testing was good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043828120

From rrich at openjdk.org  Mon Jul  7 13:23:46 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 13:23:46 GMT
Subject: jmx-dev RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <HWGh_N895W3yaN58d5RuY2Faam-y1PFlcjJ0_2GhefE=.fe327f62-07cc-452b-8369-63f13db6aae7@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

Thanks for the reviews and feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3045085386

From rrich at openjdk.org  Mon Jul  7 13:23:47 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 13:23:47 GMT
Subject: jmx-dev Integrated: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <KL2hCcdf0PhXI4_hqW8DO3K3H8YGPqlohzFV7theWMQ=.9d0a5ffb-6198-4eee-8e49-19854b773d57@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

This pull request has now been integrated.

Changeset: fea73c1d
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining

Reviewed-by: alanb, mdoerr, lmesnik

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

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

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: jmx-dev RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From rrich at openjdk.org  Wed Jul  9 07:50:49 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 9 Jul 2025 07:50:49 GMT
Subject: jmx-dev [jdk25] RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
Message-ID: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>

This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.

Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

Thanks, Richard.

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

Commit messages:
 - Backport fea73c1d40441561a246f2a09a739367cfc197ea

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

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

From mdoerr at openjdk.org  Wed Jul  9 07:50:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Jul 2025 07:50:50 GMT
Subject: jmx-dev [jdk25] RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
Message-ID: <e5XosXeJhgAYcWIowegj7r_Shnl3jsSnOMtHrTGxtW8=.696c7e24-0ba6-43cc-be77-fc5cec131810@github.com>

On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.
> 
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
> 
> Thanks, Richard.

This testfix backport makes sense.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-2996597109

From kevinw at openjdk.org  Wed Jul  9 08:15:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Jul 2025 08:15:38 GMT
Subject: jmx-dev [jdk25] RFR: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
Message-ID: <bzR8VjJoBQzoaQ6K6EVwYcTWN07omjPFQHupqV5q7Bo=.a39c5aa6-9f2b-4108-999e-1853539f8af2@github.com>

On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.
> 
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
> 
> Thanks, Richard.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-3000513381

From kevinw at openjdk.org  Wed Jul  9 13:00:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Jul 2025 13:00:48 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
Message-ID: <xcOems_zSPNX_cDaxqmj371JdxzDznAkdM7qjXhJ7BY=.e89737ef-056c-44d1-8d92-0f0a21700337@github.com>

On Tue, 1 Jul 2025 08:52:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further doc update
>  - Test udpate (listIterator)

CSR is approved, will need to get re-review or additional review 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3052582311

From sspitsyn at openjdk.org  Wed Jul  9 23:18:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 23:18:39 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
Message-ID: <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>

On Tue, 1 Jul 2025 08:52:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further doc update
>  - Test udpate (listIterator)

Changes requested by sspitsyn (Reviewer).

test/jdk/javax/management/generified/ListTypeCheckTest.java line 105:

> 103:                         ListIterator iter2 = al.listIterator();
> 104:                         Object x2 = iter2.next();
> 105:                         iter2.add("blah");

Nit: The case #6 is exactly the same as #5.
Q: Why is it needed?
I'd suggest to add a comment explaining this case.
The line 105 should have a comment as at the line 99.
In general, this test has a lack of comments explaining tests cases (was before your fix).

test/jdk/javax/management/generified/ListTypeCheckTest.java line 110:

> 108:                         throw new Exception("test wrong");
> 109:                 }
> 110:                 throw new Exception("op " + i + " allowed but should fail on " + al.getClass());

Nit: This is confusing. If it is allowed then why should it fail.
At least, it needs to be explained somewhere in the tests.

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

PR Review: https://git.openjdk.org/jdk/pull/25856#pullrequestreview-3003366010
PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196169023
PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196171012

From rrich at openjdk.org  Thu Jul 10 07:37:46 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 10 Jul 2025 07:37:46 GMT
Subject: jmx-dev [jdk25] Integrated: 8360599: [TESTBUG]
 DumpThreadsWithEliminatedLock.java fails because of unstable inlining
In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
Message-ID: <FMTsVB7Pm2hrnwxOCPikgthpCkL8Pt-gdZ4QW0wnOBo=.3f01b266-1820-4618-9aa5-f44d288ab00d@github.com>

On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.
> 
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
> 
> Thanks, Richard.

This pull request has now been integrated.

Changeset: 532b1c73
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/532b1c732edb2873afead4d12721a938cec8879f
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining

Reviewed-by: mdoerr, kevinw
Backport-of: fea73c1d40441561a246f2a09a739367cfc197ea

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

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

From kevinw at openjdk.org  Thu Jul 10 07:58:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Jul 2025 07:58:00 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v6]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <D7YOIjkqv5D4mYbb0f2mFGabwlSLDNBQaaXAVY540dE=.c24301ae-7966-463c-b939-0633aab0eff3@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Test comment update
 - Test comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/a2a28dde..7d3728d4

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

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

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

From kevinw at openjdk.org  Thu Jul 10 07:58:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Jul 2025 07:58:00 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
 <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>
Message-ID: <D1xWa9yzLG2YGiX--VDsSpyw5ttrsPIhvjvZhMhszdc=.8b1e6f2d-b207-43ee-ae8c-d4a3b2fe26b0@github.com>

On Wed, 9 Jul 2025 23:14:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further doc update
>>  - Test udpate (listIterator)
>
> test/jdk/javax/management/generified/ListTypeCheckTest.java line 105:
> 
>> 103:                         ListIterator iter2 = al.listIterator();
>> 104:                         Object x2 = iter2.next();
>> 105:                         iter2.add("blah");
> 
> Nit: The case #6 is exactly the same as #5.
> Q: Why is it needed?
> I'd suggest to add a comment explaining this case.
> The line 105 should have a comment as at the line 99.
> In general, this test has a lack of comments explaining tests cases (was before your fix).

These cases test the ListIterator operations, one case for set, one case for add.  Will update with comment to clarify.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196896204

From kevinw at openjdk.org  Thu Jul 10 08:11:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Jul 2025 08:11:41 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
 <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>
Message-ID: <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com>

On Wed, 9 Jul 2025 23:16:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further doc update
>>  - Test udpate (listIterator)
>
> test/jdk/javax/management/generified/ListTypeCheckTest.java line 110:
> 
>> 108:                         throw new Exception("test wrong");
>> 109:                 }
>> 110:                 throw new Exception("op " + i + " allowed but should fail on " + al.getClass());
> 
> Nit: This is confusing. If it is allowed then why should it fail.
> At least, it needs to be explained somewhere in the tests.

Thanks Serguei, I hope I've addressed both comments with additional comment updates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196935071

From kevinw at openjdk.org  Thu Jul 10 08:21:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Jul 2025 08:21:47 GMT
Subject: jmx-dev Integrated: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <VAki9V4dCIxxECClqn_XxSPFQxWAkS83ZoxqdN3ME8w=.11e38480-2d65-4eca-80b8-8061e8345081@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

This pull request has now been integrated.

Changeset: 13e0f996
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13e0f99626ed58958bf0b581be95934f0b218979
Stats:     649 lines in 6 files changed: 0 ins; 644 del; 5 mod

8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport

Reviewed-by: dfuchs, sspitsyn

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

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

From sspitsyn at openjdk.org  Thu Jul 10 15:08:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 15:08:44 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v5]
In-Reply-To: <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
 <YBKtOOt5CD7XDRd8JrNJycSvlQP_IshS8OAxDIT4qlw=.852e7868-8282-486b-8837-bcde525b770d@github.com>
 <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com>
Message-ID: <YPk3552yuVUCmJz94a3OdEhxg6MSBPFxc9YeqtbmoFM=.f33c7f0e-cb56-4a7c-aca8-0a38832f523e@github.com>

On Thu, 10 Jul 2025 08:08:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/generified/ListTypeCheckTest.java line 110:
>> 
>>> 108:                         throw new Exception("test wrong");
>>> 109:                 }
>>> 110:                 throw new Exception("op " + i + " allowed but should fail on " + al.getClass());
>> 
>> Nit: This is confusing. If it is allowed then why should it fail.
>> At least, it needs to be explained somewhere in the tests.
>
> Thanks Serguei, I hope I've addressed both comments with additional comment updates.

Thank you for the update, Kevin!
I've almost done with reviewing but want to make one more pass, especially though the updated tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2198004375

From sspitsyn at openjdk.org  Thu Jul 10 15:12:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 15:12:39 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v6]
In-Reply-To: <D7YOIjkqv5D4mYbb0f2mFGabwlSLDNBQaaXAVY540dE=.c24301ae-7966-463c-b939-0633aab0eff3@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <D7YOIjkqv5D4mYbb0f2mFGabwlSLDNBQaaXAVY540dE=.c24301ae-7966-463c-b939-0633aab0eff3@github.com>
Message-ID: <lHW5b_jF5Ha72Zn9fwSzjySLbduPnSnKUMyMdd4zEgU=.c2120850-59b8-4d1b-a58c-fdc4e7a42c8e@github.com>

On Thu, 10 Jul 2025 07:58:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Test comment update
>  - Test comment update

It looks good to me now.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25856#pullrequestreview-3006173062

From kevinw at openjdk.org  Thu Jul 10 15:23:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Jul 2025 15:23:52 GMT
Subject: jmx-dev Integrated: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <UktyGZbfwkFDCdiU1WgCnLcUamzN3GxFAYr3Q0n4Pbc=.dee261b5-bc58-4110-94f3-ea6dd516819f@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

This pull request has now been integrated.

Changeset: cbc7090b
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbc7090b91f4ce84117a04036028076373ab805e
Stats:     300 lines in 5 files changed: 68 ins; 171 del; 61 mod

8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object

Reviewed-by: sspitsyn

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

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

From mbaesken at openjdk.org  Thu Jul 24 16:39:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Jul 2025 16:39:24 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>

On Tue, 20 May 2025 15:32:21 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 you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Are you sure the perfstat functionality is always available ? 
In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this .

If we only address minimum AIX 7.2 we can probably simplify this approach or even go away from the current dynamic loading approach.
See also https://bugs.openjdk.org/browse/JDK-8222719  where I did already some cleanup (but kept the  AIX 7.1 vs. 7.2 ) .

There is still an fflush(stdout);  in UnixOperatingSystem.c  - guess this is not needed any more?

Maybe you can check the system tools you mentioned with 'trace' or 'tprof' or something similar to find out more about what they do and why they differ?

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

> 55: 
> 56:     ret = perfstat_cpu_total(NULL, &cpu_total, sizeof(perfstat_cpu_total_t), 1);
> 57:     if (ret <= 0) {

I noticed that we check for retval < 0 in os_perf_aix.cpp, should we align this in some way ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2896875648
PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3048932756
PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3056023114
PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3106958683
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2099545296

From sroy at openjdk.org  Thu Jul 24 16:39:24 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 24 Jul 2025 16:39:24 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
Message-ID: <bQ0lqmXKtwb0tWpv6wTUrxzLDBYoGtjxQn69fd5BHbI=.9745b4fd-f1db-443d-b249-42eba072a1d0@github.com>

On Wed, 21 May 2025 07:21:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this .

I tried with a standalone program and did not face any issues.

@MBaesken  would it be possible for you to try this patch once to see if the load values are realistic / accurate ? 
Else if you can provide some use case that I can try.

> There is still an fflush(stdout);  in UnixOperatingSystem.c  - guess this is not needed any more?

@MBaesken  we tried testing both semeru and temurin again system tools like nmon/topas but the values differ for both. 
This probably has something to do with how topas/nmon is working behind the hood.. Do you suggest any different test ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908856936
PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908858697
PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3103606269

From mbaesken at openjdk.org  Thu Jul 24 16:39:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Jul 2025 16:39:24 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <bQ0lqmXKtwb0tWpv6wTUrxzLDBYoGtjxQn69fd5BHbI=.9745b4fd-f1db-443d-b249-42eba072a1d0@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
 <bQ0lqmXKtwb0tWpv6wTUrxzLDBYoGtjxQn69fd5BHbI=.9745b4fd-f1db-443d-b249-42eba072a1d0@github.com>
Message-ID: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com>

On Mon, 26 May 2025 07:39:59 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this .
> 
> I tried with a standalone program and did not face any issues.

I was more thinking about different AIX machines setups/OS levels/installations. Is the perfstat functionality always there 'these days' ?

> would it be possible for you to try this patch once to see if the load values are realistic / accurate ?

Not 100% sure how, should we compare with values provided by other tools (system tools etc.) ?

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

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

From sroy at openjdk.org  Thu Jul 24 16:39:24 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 24 Jul 2025 16:39:24 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
Message-ID: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@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 you should not forget to remove the two excludes from jdk/test/ProblemList.txt:

com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

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

Commit messages:
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - cleanup
 - system cpu load
 -  restore problem list
 - cpu process load

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8030957
  Stats: 78 lines in 2 files changed: 72 ins; 2 del; 4 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 Jul 24 16:39:25 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 24 Jul 2025 16:39:25 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
 <bQ0lqmXKtwb0tWpv6wTUrxzLDBYoGtjxQn69fd5BHbI=.9745b4fd-f1db-443d-b249-42eba072a1d0@github.com>
 <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com>
Message-ID: <oMd3XSvBPbF47lImsx5La6OHlhpJOB5ZtM5YythZYXQ=.cd0a812a-5813-466b-b0e6-8bd5aa674521@github.com>

On Mon, 26 May 2025 07:57:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > > Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this .
> > 
> > 
> > I tried with a standalone program and did not face any issues.
> 
> I was more thinking about different AIX machines setups/OS levels/installations. Is the perfstat functionality always there 'these days' ?

Hi @MBaesken It seems perfstat is available since AIX 5. I see there is dynamic loading done in libperfstat.cpp.  How to confirm if that is necessary ? I did not face issues in this program and also standalone C++ program on AIX 7.2

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

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

From mbaesken at openjdk.org  Thu Jul 24 16:39:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Jul 2025 16:39:25 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <oMd3XSvBPbF47lImsx5La6OHlhpJOB5ZtM5YythZYXQ=.cd0a812a-5813-466b-b0e6-8bd5aa674521@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
 <bQ0lqmXKtwb0tWpv6wTUrxzLDBYoGtjxQn69fd5BHbI=.9745b4fd-f1db-443d-b249-42eba072a1d0@github.com>
 <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com>
 <oMd3XSvBPbF47lImsx5La6OHlhpJOB5ZtM5YythZYXQ=.cd0a812a-5813-466b-b0e6-8bd5aa674521@github.com>
Message-ID: <fCBqLq8BVW9_gNqgVLXis2V-Dh9SymgLTauHz9CnASw=.17c83995-5ff8-428f-9081-d56729fbbb67@github.com>

On Mon, 7 Jul 2025 14:30:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> How to confirm if that is necessary ? I did not face issues in this program and also standalone C++ program on AIX 7.2

We did this not only because of  (un)availability of libperfstat , but also to address different versions  (with different functionality) of libperfstat at runtime.

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

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

From duke at openjdk.org  Wed Jul 30 14:52:50 2025
From: duke at openjdk.org (Lei Zhu)
Date: Wed, 30 Jul 2025 14:52:50 GMT
Subject: jmx-dev RFR: 8362533: Tests sun/management/jmxremote/bootstrap/*
 duplicate VM flags
Message-ID: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>

Hi all,

`ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.

Thanks!

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

Commit messages:
 - 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags

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

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

From sroy at openjdk.org  Wed Jul 30 16:55:11 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 30 Jul 2025 16:55:11 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v2]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <D90hHLBOOI5l8F1yCYtTjG54LKvWDjC2CQLWuNlUcK0=.e12d73c7-fe24-4de9-afcd-e9cb1d25ad98@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 you should not forget to remove the two excludes 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 seven commits:

 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - cleanup
 - system cpu load
 -  restore problem list
 - cpu process load

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

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=01
  Stats: 79 lines in 2 files changed: 72 ins; 3 del; 4 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  Wed Jul 30 16:55:12 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 30 Jul 2025 16:55:12 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
Message-ID: <IY10szsvhHNfffDY3woOmZfg-v8c7yepDaZeXkHyHl4=.72a16b25-c2d8-4325-a90a-3006b9f9a011@github.com>

On Wed, 23 Jul 2025 10:47:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Maybe you can check the system tools you mentioned with 'trace' or 'tprof' or something similar to find out more about what they do and why they differ?

Couldn't get much insights from that .

I tried one case where I ran the same class file against Temurin and Semeru java binaries. I see almost similar cpu load values reported by both.

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

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

From lmesnik at openjdk.org  Wed Jul 30 22:09:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 30 Jul 2025 22:09:00 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags
In-Reply-To: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
Message-ID: <Imvbo3Jss-3ZYZKt9TaZgqoZC0nWihCgpBWIWF9-8bg=.0564712a-ea63-47c3-a715-912ff984a94f@github.com>

On Wed, 30 Jul 2025 14:47:54 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
> 
> Thanks!

Changes requested by lmesnik (Reviewer).

test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java line 183:

> 181: 
> 182:             List<String> command = new ArrayList<>();
> 183:             Collections.addAll(command, Utils.getTestJavaOpts());

Comment generic to all three test fixes:
Shouldn't be
command.add(TEST_CLASS_PATH);
            command.add(className);
also removed?
The ProcessTools.createTestJavaProcessBuilder(command); 
uses standard classpath that should fit this test needs.
If needed,
property "test.noclasspath", mgith be use to don't add classpath. See 
jdk/test/lib/process/ProcessTools.java:161
 private static ProcessBuilder createJavaProcessBuilder(String... command) {
...
 String noCPString = System.getProperty("test.noclasspath", "false");

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

PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3073452917
PR Review Comment: https://git.openjdk.org/jdk/pull/26555#discussion_r2243946685

From duke at openjdk.org  Thu Jul 31 04:54:39 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 31 Jul 2025 04:54:39 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
Message-ID: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>

> Hi all,
> 
> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
> 
> Thanks!

Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:

  remove duplicate -cp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26555/files
  - new: https://git.openjdk.org/jdk/pull/26555/files/8e3ddcd7..7a5ff15f

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

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

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

From duke at openjdk.org  Thu Jul 31 04:56:54 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 31 Jul 2025 04:56:54 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <Imvbo3Jss-3ZYZKt9TaZgqoZC0nWihCgpBWIWF9-8bg=.0564712a-ea63-47c3-a715-912ff984a94f@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <Imvbo3Jss-3ZYZKt9TaZgqoZC0nWihCgpBWIWF9-8bg=.0564712a-ea63-47c3-a715-912ff984a94f@github.com>
Message-ID: <-Nda3pgRAgrJ0gcMYVu1N2YjAKSsMsALexoVdOjK0ks=.54721a85-6b51-4f5b-bdf7-8aa683808fc3@github.com>

On Wed, 30 Jul 2025 22:05:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Comment generic to all three test fixes: Shouldn't be command.add(TEST_CLASS_PATH); command.add(className); also removed? The ProcessTools.createTestJavaProcessBuilder(command); uses standard classpath that should fit this test needs. If needed, property "test.noclasspath", mgith be use to don't add classpath. See jdk/test/lib/process/ProcessTools.java:161 private static ProcessBuilder createJavaProcessBuilder(String... command) { ... String noCPString = System.getProperty("test.noclasspath", "false");

Thanks for review, the duplicate `-cp` has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26555#discussion_r2244348086

From lmesnik at openjdk.org  Thu Jul 31 06:06:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 31 Jul 2025 06:06:00 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
Message-ID: <pF6szZveM8_Ju25SIMoVmluJkvGOT7XUQuLSNb1Bk04=.01837a22-f12f-442b-b86f-89f8fe99cbaa@github.com>

On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
>> 
>> Thanks!
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate -cp

Looks good! Thank you for fixing and addressing feedback.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3074076889

From duke at openjdk.org  Thu Jul 31 07:11:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 31 Jul 2025 07:11:54 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
Message-ID: <Df-NwaaXRWDCuqbgcMQ4VPQn6StcnMk4ob-QGMX-rtQ=.ba650f15-e285-401d-b069-272f59986289@github.com>

On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
>> 
>> Thanks!
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate -cp

@Korov 
Your change (at version 7a5ff15f74afaa6bbe3e42f4458cd131ba4b8319) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26555#issuecomment-3138803482

From sspitsyn at openjdk.org  Thu Jul 31 07:18:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 07:18:54 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
Message-ID: <xXZC6Rwy2hm4ZVyDljkoELgjQaZrtM5YpKtpPhF06NA=.3ec4d928-6ec2-4e09-8084-424a274006ab@github.com>

On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
>> 
>> Thanks!
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate -cp

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3074246189

From duke at openjdk.org  Thu Jul 31 09:03:00 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 31 Jul 2025 09:03:00 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <xXZC6Rwy2hm4ZVyDljkoELgjQaZrtM5YpKtpPhF06NA=.3ec4d928-6ec2-4e09-8084-424a274006ab@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
 <xXZC6Rwy2hm4ZVyDljkoELgjQaZrtM5YpKtpPhF06NA=.3ec4d928-6ec2-4e09-8084-424a274006ab@github.com>
Message-ID: <V1YgEM7zWAjjYX9kIMP_rEgRW_cjzm_1ftUe4pA-HQA=.bdc27d52-a83a-4abc-acde-e7a48b5818a5@github.com>

On Thu, 31 Jul 2025 07:15:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove duplicate -cp
>
> Looks good.

@sspitsyn Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26555#issuecomment-3139123313

From kevinw at openjdk.org  Thu Jul 31 13:15:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 31 Jul 2025 13:15:02 GMT
Subject: jmx-dev RFR: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags [v2]
In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
Message-ID: <sfMcesDrfgGXonjkPPs5aHMF1FW0Cac0kkvgRC0HjOY=.227e3d2a-ac8a-448c-abe2-8d763be97b18@github.com>

On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
>> 
>> Thanks!
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate -cp

Looks good.
(More than trivial, but good. 8-) )

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3075384021

From duke at openjdk.org  Thu Jul 31 13:15:03 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 31 Jul 2025 13:15:03 GMT
Subject: jmx-dev Integrated: 8362533: Tests
 sun/management/jmxremote/bootstrap/* duplicate VM flags
In-Reply-To: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
Message-ID: <hpKcsa0UUa5ZzbkmYsFXxxMCSMvszLTYYvyjcqffLtY=.da82df82-9f51-4fcc-ae50-37beebd43e03@github.com>

On Wed, 30 Jul 2025 14:47:54 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 458f033d
Author:    Lei Zhu <korov9.c at gmail.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/458f033d4dd3c646028b2f9bab88f9a308cad4af
Stats:     21 lines in 3 files changed: 0 ins; 17 del; 4 mod

8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags

Reviewed-by: lmesnik, sspitsyn, kevinw

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

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

From abarashev at openjdk.org  Thu Jul 31 20:55:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 31 Jul 2025 20:55:48 GMT
Subject: jmx-dev RFR: 8364484: misc tests fail with Received fatal alert:
 handshake_failure
Message-ID: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>

Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change.

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

Commit messages:
 - 8364484 misc tests fail with Received fatal alert: handshake_failure

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

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

From abarashev at openjdk.org  Thu Jul 31 21:00:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 31 Jul 2025 21:00:09 GMT
Subject: jmx-dev RFR: 8364484: misc tests fail with Received fatal
 alert: handshake_failure [v2]
In-Reply-To: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
Message-ID: <JS9RVIsQ78-wBX7m_eviEUX2tm3ZmNkWRs6kwYPjtHA=.5e3a8d07-d7ac-4ec6-8124-af59c5fc8db6@github.com>

> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  This test has a 2nd main method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26583/files
  - new: https://git.openjdk.org/jdk/pull/26583/files/7139cb3c..a4c25654

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

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

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

From ascarpino at openjdk.org  Thu Jul 31 21:15:55 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 31 Jul 2025 21:15:55 GMT
Subject: jmx-dev RFR: 8364484: misc tests fail with Received fatal
 alert: handshake_failure [v2]
In-Reply-To: <JS9RVIsQ78-wBX7m_eviEUX2tm3ZmNkWRs6kwYPjtHA=.5e3a8d07-d7ac-4ec6-8124-af59c5fc8db6@github.com>
References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
 <JS9RVIsQ78-wBX7m_eviEUX2tm3ZmNkWRs6kwYPjtHA=.5e3a8d07-d7ac-4ec6-8124-af59c5fc8db6@github.com>
Message-ID: <f6GUsFWVC5udAmUmMqoxJfVAIwwRP4KIdI40bpZdwik=.755e24b4-cfce-4364-ae1d-41475296475c@github.com>

On Thu, 31 Jul 2025 21:00:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This test has a 2nd main method

The change looks fine

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26583#pullrequestreview-3076899452

From hchao at openjdk.org  Thu Jul 31 21:26:59 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 31 Jul 2025 21:26:59 GMT
Subject: jmx-dev RFR: 8364484: misc tests fail with Received fatal
 alert: handshake_failure [v2]
In-Reply-To: <JS9RVIsQ78-wBX7m_eviEUX2tm3ZmNkWRs6kwYPjtHA=.5e3a8d07-d7ac-4ec6-8124-af59c5fc8db6@github.com>
References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
 <JS9RVIsQ78-wBX7m_eviEUX2tm3ZmNkWRs6kwYPjtHA=.5e3a8d07-d7ac-4ec6-8124-af59c5fc8db6@github.com>
Message-ID: <6qjc4GhBwGw7iXBS4egXWWkXOwgbpIEH24SqKaC8tK8=.88b9d00c-810f-41c2-908c-ea6f081ad552@github.com>

On Thu, 31 Jul 2025 21:00:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This test has a 2nd main method

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/26583#pullrequestreview-3076921185

From abarashev at openjdk.org  Thu Jul 31 21:27:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 31 Jul 2025 21:27:00 GMT
Subject: jmx-dev Integrated: 8364484: misc tests fail with Received fatal
 alert: handshake_failure
In-Reply-To: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com>
Message-ID: <OKAe-Ch0gXsU3W5rMS1ZOy2ZqQHF83coChRfuY0OLZg=.0a4138c6-d19d-4cd1-a409-2723b75f440a@github.com>

On Thu, 31 Jul 2025 20:49:52 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change.

This pull request has now been integrated.

Changeset: 724e8c07
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/724e8c076e1aed05de893ef9366af0e62cc2ac2b
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8364484: misc tests fail with Received fatal alert: handshake_failure

Reviewed-by: ascarpino

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

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