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