From dholmes at openjdk.org  Mon Dec  1 04:21:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Dec 2025 04:21:52 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>

On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142:

> 140:      *
> 141:      * @return true if resource limits are supported in the current configuration
> 142:      * @throws Exception

I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true of throws. These should just be void functions with names like `check_canUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2575563949

From mbaesken at openjdk.org  Mon Dec  1 07:47:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Dec 2025 07:47:59 GMT
Subject: RFR: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
In-Reply-To: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
References: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
Message-ID: <CgqqSt0O3yY_huijBz_x8wW54g4dvQtNE0CqbywLBa8=.5da0cb3a-77e4-4edb-a325-d90a1dd98c39@github.com>

On Fri, 28 Nov 2025 10:23:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28552#issuecomment-3595065394

From mbaesken at openjdk.org  Mon Dec  1 07:48:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Dec 2025 07:48:00 GMT
Subject: Integrated: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
In-Reply-To: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
References: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
Message-ID: <iYKpLU-ow4jhNk6-p8jpxp9nOx7EHNivmUez8eiIqvo=.82292b00-9ab8-4dee-a4d8-ebac478cec57@github.com>

On Fri, 28 Nov 2025 10:23:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

This pull request has now been integrated.

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

8372588: [asan] serviceability/sa/TestJmapCore.java and TestJmapCoreMetaspace.java fail after recent improvements

Reviewed-by: stuefe, azeller, lucy

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

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

From aartemov at openjdk.org  Mon Dec  1 10:35:49 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 1 Dec 2025 10:35:49 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v18]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <KgVvaAA736dqunpCb06JwU0kjstJ4vUejA6B-j2sQVk=.c5b7c86a-c880-4583-b16f-9c6c41758f9b@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed whitespace error.
 - 8366659: Refactoring.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed tests.
 - 8366659: Fixed tests.
 - 8366659: Refactored tests.
 - 8366659: Added bool arg to notify_contended_enter
 - 8366659: Refactored the big test into 3 smaller tests.
 - 8366659: Addressed reviewer's comments.
 - ... and 24 more: https://git.openjdk.org/jdk/compare/ef5e744a...8283d9c0

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=17
  Stats: 1277 lines in 9 files changed: 828 ins; 427 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From djelinski at openjdk.org  Mon Dec  1 11:03:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Dec 2025 11:03:15 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v7]
In-Reply-To: <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
Message-ID: <Q15PCCegrjbDS-CKa2jsyLoOeaAyvKLV3a5018Deb9g=.70160d1c-2168-4cbe-aa05-45569271111c@github.com>

On Mon, 24 Nov 2025 17:22:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Updated IPAddressDNSIdentities and confirmed test fails for correct reason
>  - Merge branch 'master' into update-md5-certs
>  - Updated SAN methods in CertificateBuilder to take multiple names
>  - Merge branch 'master' into update-md5-certs
>  - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
>  - removed unused keystore files, fixed certificate chain
>  - Merge branch 'master' into update-md5-certs
>  - changed line wrapping
>  - removed unnecessary comment and made getSSLContext(...) private
>  - changed tests to use SecurityUtils.removeDisabled*Algs methods
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d0629285...ea9c2dce

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3524380076

From mdonovan at openjdk.org  Mon Dec  1 12:21:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 1 Dec 2025 12:21:04 GMT
Subject: Integrated: 8353738: Update TLS unit tests to not use certificates
 with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <KiVDvQMrcUC7gXrOaTXnGTgkn39UhSTGczGfyPrlU0Q=.4b6c2f93-e61a-4a58-883a-7501554ac7b8@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: f5eecc45
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5eecc454eb78fc1a3714dfe3cb94113238dd3ac
Stats:     3481 lines in 14 files changed: 402 ins; 2957 del; 122 mod

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

Reviewed-by: djelinski, abarashev

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

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

From cnorrbin at openjdk.org  Mon Dec  1 12:45:06 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 12:45:06 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  reworked check docker/resourcelimit functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28557/files
  - new: https://git.openjdk.org/jdk/pull/28557/files/e9297412..986b3923

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

  Stats: 112 lines in 27 files changed: 0 ins; 69 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/28557.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28557/head:pull/28557

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

From cnorrbin at openjdk.org  Mon Dec  1 12:52:48 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 12:52:48 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>
Message-ID: <4wL0GNT4iNlJ95Dt43mwpRYI82DIXa6mFfLGvaVpH0w=.a8643ade-7687-41e8-b378-d3faae4084b2@github.com>

On Mon, 1 Dec 2025 04:18:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reworked check docker/resourcelimit functions
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142:
> 
>> 140:      *
>> 141:      * @return true if resource limits are supported in the current configuration
>> 142:      * @throws Exception
> 
> I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true or else throws. These should just be void functions with names like `checkCanUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers.

I agree that it could be made clearer.

I reworked both `canUseResourceLimits()` and `canTestDocker()` into `void` functions that only throw. So 

```c++
if (!DockerTestUtils.canTestDocker() || !DockerTestUtils.canUseResourceLimits()) {
    return;
}


Instead becomes:

```c++
DockerTestUtils.checkCanTestDocker();
DockerTestUtils.checkCanUseResourceLimits();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2576955639

From coleenp at openjdk.org  Mon Dec  1 15:02:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 15:02:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Added a comment for checking interface guard after array guard.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/06d6a186..7f234078

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

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

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

From sgehwolf at openjdk.org  Mon Dec  1 15:33:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 1 Dec 2025 15:33:10 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK?

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

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525625824

From cnorrbin at openjdk.org  Mon Dec  1 15:44:31 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 15:44:31 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
 <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>
Message-ID: <FpOD6g0pXtPaH7KZ-mJFSJp68HPJBSuj1AHf-1DyPJE=.d751cd3c-d565-459e-848b-e9390370d001@github.com>

On Mon, 1 Dec 2025 15:30:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK?

I believe it's an acceptable trade-off. Many tests would need the dependancy anyway in addition to the full check for resource limits. I would rather abstract that away in a utility function, at the cost of a few other tests also requiring the module.

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

PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3597274354

From sgehwolf at openjdk.org  Mon Dec  1 16:05:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 1 Dec 2025 16:05:51 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <nPcGPmWbKt_fzUNGhwXppzCIunbqKn857JjfDvXOUEY=.23be77a4-2ee8-4baa-aaf6-753d1187713a@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

OK

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525791884

From duke at openjdk.org  Mon Dec  1 19:00:12 2025
From: duke at openjdk.org (Tres Finocchiaro)
Date: Mon, 1 Dec 2025 19:00:12 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
Message-ID: <sPgdp1XiQvm6vQfasfg22c0rnirJpjCzoQ6CFuaDxfY=.6177b0e5-d2a9-4e77-aa88-b36fb7cedee2@github.com>

On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

Someone please bump this.  I don't have access to.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3598373427

From coleenp at openjdk.org  Mon Dec  1 19:16:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:16:58 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
Message-ID: <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>

On Wed, 26 Nov 2025 22:44:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing to initialize _is_disabler_at_start

Excellent work. Thank you for answering my questions.  There's one click suggested change.

src/hotspot/share/opto/library_call.cpp line 3052:

> 3050: //
> 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true);
> 3052: // carrier->set_is_in_VTMS_transition(true);

Suggestion:

// java_lang_Thread::set_is_in_vthread_transition(vthread, true);
// carrier->set_is_in_vthread_transition(true);

src/hotspot/share/opto/library_call.cpp line 3058:

> 3056: // if (disable_requests > 0) {
> 3057: //   slow path: runtime call
> 3058: // }

The comment is helpful, thanks.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3526451726
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578205190
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578206636

From coleenp at openjdk.org  Mon Dec  1 19:16:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:16:59 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <nkiv-uD161ABXR446aJmfavXlgpGUkSoUn7ciurOUL4=.a7b1d499-b363-4ae2-ab7d-77507b890a0f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <nkiv-uD161ABXR446aJmfavXlgpGUkSoUn7ciurOUL4=.a7b1d499-b363-4ae2-ab7d-77507b890a0f@github.com>
Message-ID: <cfwM4cW61LUM-Uu7MpSH6tUh2nEGDdFp51zm8br0jQo=.42356c39-13be-4059-b762-c406b66fb019@github.com>

On Wed, 26 Nov 2025 22:46:37 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 3671:
>> 
>>> 3669: 
>>> 3670: JVM_ENTRY(void, JVM_VirtualThreadStartFinalTransition(JNIEnv* env, jobject vthread))
>>> 3671:   oop vt = JNIHandles::resolve_external_guard(vthread);
>> 
>> Why do the opto runtime versions set is_in_VTMTS_transition in both the java.lang.Thread and JavaThread and these don't?
>
> Because we set them in the intrinsic when trying to start the transition. Method `MountUnmountDisabler::start_transition` expects them to be false so we need to clear them in the opto versions.

Not sure what I was looking at when I made this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578213839

From coleenp at openjdk.org  Mon Dec  1 19:17:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:01 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>
Message-ID: <nOCP2N0syvhqm5y7RjeZ0KpW1_OOBCn2zZ0xSi4I08U=.a5408d06-5e36-49b7-ab48-7e0ecca43a5f@github.com>

On Wed, 26 Nov 2025 22:47:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1772:
>> 
>>> 1770: 
>>> 1771:   assert(java_thread != nullptr, "sanity check");
>>> 1772:   assert(!java_thread->is_in_VTMS_transition(), "sanity check");
>> 
>> Why don't you need these asserts anymore?
>
> We can?t assert this because it could be temporarily set by the target while trying to transition. Previously we had two fields in JavaThread, `_VTMS_transition_mark` and `_is_in_VTMS_transition`. `_VTMS_transition_mark` was set first (checked by the disabler), and if transitions were disabled we waited. Once the transition could start we set `_is_in_VTMS_transition`. 
> Going over the changes I see I removed one assert in `JvmtiEnvBase::get_vthread_jvf` that should be okay to keep, so I restored it. Also added an assert in `JavaThread::is_in_VTMS_transition()` (now `is_in_vthread_transition`) to verify that if it?s accessed from another thread then it has to be done from a safe context where the value will not change?right after checking.

okay.  seems like a better place for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578224144

From coleenp at openjdk.org  Mon Dec  1 19:17:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:03 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
 <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
Message-ID: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>

On Wed, 26 Nov 2025 22:48:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Why is there the same flag with the same name in both the Java class and C++ JavaThread?  Might be an efficient cache, so something should say that (if true).
>
> The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition.

So why do you need one in java_lang_Thread then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578256282

From coleenp at openjdk.org  Mon Dec  1 19:17:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:04 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <G8Y1SK9ja-KTRTf8ZjkrTpP9-BuGT3EE_XR_gNKOgmo=.2fbf4064-83a8-4466-963e-0638e4953b76@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
 <G8Y1SK9ja-KTRTf8ZjkrTpP9-BuGT3EE_XR_gNKOgmo=.2fbf4064-83a8-4466-963e-0638e4953b76@github.com>
Message-ID: <Nz_gL9kCqf3GKbdB4T4T_UoE8J45NLTji0LwNNwkZqM=.4de33567-671c-4dd5-9475-a1d9448bfcea@github.com>

On Tue, 25 Nov 2025 23:49:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 126:
>> 
>>> 124:          || global_start_transition_disable_count() > base_disable_count
>>> 125:          JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()));
>>> 126: }
>> 
>> I like this approach with the JVMTIStartTransition and JVMTIEndTransition helper classes. It is a nice way to decouple the JVMTI part of the protocol. Introducing the `is_start_transition_disabled()` function was also long desired. Also, I like the functions `start_transition()` and `end_transition()` became pretty simple and clean!
>
> This is the function that needs a comment why you're testing all these things (and why base_disable_count is one for JVMTI). It's nice as a function that tests all the different values.

Looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578310137

From coleenp at openjdk.org  Mon Dec  1 19:17:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:06 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <dILqkj4lXJ4BFqiA_1bQoNKzH2HGfJkhCgpvrioOI2o=.d1cc45e7-e881-46f1-8174-ce5a4758e3e9@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>
 <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
 <dILqkj4lXJ4BFqiA_1bQoNKzH2HGfJkhCgpvrioOI2o=.d1cc45e7-e881-46f1-8174-ce5a4758e3e9@github.com>
Message-ID: <Vyw5XV3F-IDMcsHikh30-Dfg63fGhv_svd314qvzZw4=.926af9b2-41ec-4117-b76d-aeee5555063e@github.com>

On Wed, 26 Nov 2025 07:33:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This could be a simple cleanup of all these occurrences later.
>
> Yes this is terribly obscure (doing the assignment in the loop condition check - surprised that is even allowed) and also violates the style-guide in relation to implicit booleans. But frankly it is an awful use of a for-loop in my opinion.

Filed https://bugs.openjdk.org/browse/JDK-8372840 as a cleanup task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578305847

From vlivanov at openjdk.org  Mon Dec  1 19:31:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 1 Dec 2025 19:31:58 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <RNTZqITub3JNnExn66B6WObEnfMzmxCqweKFNktAKo8=.e711597d-210a-497d-a27b-9c1f40ce4552@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3526629937

From alanb at openjdk.org  Mon Dec  1 19:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Dec 2025 19:48:57 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
 <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
Message-ID: <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>

On Thu, 20 Nov 2025 23:05:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> How about removing these methods and just have an extra boolean parameter in `start/endTransition`?
>> https://github.com/pchilano/jdk/compare/JDK-8364343...pchilano:jdk:startEndTransitionsOnly
>
> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.

Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and  startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578388614

From cjplummer at openjdk.org  Mon Dec  1 21:14:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 1 Dec 2025 21:14:03 GMT
Subject: RFR: 8372809: Test
 vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
Message-ID: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>

Fix a couple of asserts that are now being triggered after the changes for [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) were introduced. I had already run into these asserts while working on [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380), and had already fixed them there. However, [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380) likely is not going to be pushed for JDK 26, so I have moved the fixes to this PR.

You can also find the fixes I moved over from [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) here: https://github.com/openjdk/jdk/pull/28485/files#diff-65eb4035b1d9bb5ceaab430461cd782069fe88c0a7d0438964c041caf0aa5eec

Tested by running failed test case a few hundred times, and also all tier5 CI svc tests, which includes a lot of JDI related testing with virtual threads enabled. Also ran tier1 CI.

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

Commit messages:
 - Cleanup some assert issues

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

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

From amenkov at openjdk.org  Mon Dec  1 21:45:48 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 1 Dec 2025 21:45:48 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v2]
In-Reply-To: <wuqaPXbGCCYwSv051DmgZ3hHozeIvMgj1yN8a91y378=.b2670ffd-9b81-4320-be80-592fb8272b38@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>
 <N7b7ttWwmLt8bJ1vNYujmYfFopZssgyB55FNoO5DbuY=.93a7d7d4-88d7-4632-b9ae-2a429936eec3@github.com>
 <wuqaPXbGCCYwSv051DmgZ3hHozeIvMgj1yN8a91y378=.b2670ffd-9b81-4320-be80-592fb8272b38@github.com>
Message-ID: <9QjsUpQDfW9h9YLwAn8ks2nUD5PfF7nfY8nx7zmvpOs=.fcc2ecc1-f97e-4fd2-b069-57c89bf00ed4@github.com>

On Thu, 27 Nov 2025 01:30:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> How about virtualThreadStartEventsEnabledForDeferredEventMode?

Super long :) But makes it much clearer, so I'm fine with it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2578821778

From dlong at openjdk.org  Mon Dec  1 21:50:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 1 Dec 2025 21:50:54 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

src/hotspot/share/oops/instanceKlass.hpp line 237:

> 235: 
> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
> 237:   InstanceKlassFlags _misc_flags;

It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:

InstanceKlassFlags _misc_flags; // contains _reference_type
AccessFlags        _access_flags;
char _reserved[2];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578843984

From dlong at openjdk.org  Mon Dec  1 22:12:52 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 1 Dec 2025 22:12:52 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

Looks good.

src/hotspot/share/opto/library_call.cpp line 4104:

> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
> 4103:     }
> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.

In other words, we are accessing subtype-specific information, so we need to determine the subtype first.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527269001
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578897794

From cjplummer at openjdk.org  Mon Dec  1 22:26:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 1 Dec 2025 22:26:53 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v3]
In-Reply-To: <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
Message-ID: <_d6s5Oiliz2OckHuA6hsnBPEkHJ2AR3LqbJwbP0VITA=.dd99cd0a-157d-43cd-a95c-5a4599a84d74@github.com>

On Thu, 20 Nov 2025 01:25:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for macOS

Overall this looks good. I made one very minor request for a comment fix. Thanks for all your efforts here1

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java line 80:

> 78:     private BsdCDebugger cdbg;
> 79: 
> 80:     // loadObjectList are filled by attach0 method

Suggestion:

    // loadObjectList is filled by attach0 method

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28284#pullrequestreview-3527245704
PR Review Comment: https://git.openjdk.org/jdk/pull/28284#discussion_r2578883005

From coleenp at openjdk.org  Mon Dec  1 22:50:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 22:50:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
Message-ID: <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>

On Mon, 1 Dec 2025 21:48:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/oops/instanceKlass.hpp line 237:
> 
>> 235: 
>> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
>> 237:   InstanceKlassFlags _misc_flags;
> 
> It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:
> 
> InstanceKlassFlags _misc_flags; // contains _reference_type
> AccessFlags        _access_flags;
> char _reserved[2];

ClassState is a u1 so that fills the u2 gap with reference_type.  So I don't think moving reference type will help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578975466

From coleenp at openjdk.org  Mon Dec  1 22:55:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 22:55:52 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
Message-ID: <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>

On Mon, 1 Dec 2025 22:09:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/opto/library_call.cpp line 4104:
> 
>> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
>> 4103:     }
>> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.
> 
> In other words, we are accessing subtype-specific information, so we need to determine the subtype first.

I can add this to the comment if you think it's helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578992154

From pchilanomate at openjdk.org  Mon Dec  1 23:00:16 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:16 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

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

  Fix comment in inline_native_vthread_start_transition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/7aa02a46..44af0ca9

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

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

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

From pchilanomate at openjdk.org  Mon Dec  1 23:00:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:17 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
 <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>
Message-ID: <m4Z0iFmXIWLMtsC9BlF0439QGNXcM3Sjrvs2e4tSRQc=.40557be4-a262-4708-90cd-1be9f80f5614@github.com>

On Mon, 1 Dec 2025 19:14:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Excellent work. Thank you for answering my questions. There's one click suggested change.
>
Thanks for the review Coleen!

> src/hotspot/share/opto/library_call.cpp line 3052:
> 
>> 3050: //
>> 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true);
>> 3052: // carrier->set_is_in_VTMS_transition(true);
> 
> Suggestion:
> 
> // java_lang_Thread::set_is_in_vthread_transition(vthread, true);
> // carrier->set_is_in_vthread_transition(true);

Fixed. Also fixed the comment above: the other caller is `startFinalTransition`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3599315673
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578999900

From pchilanomate at openjdk.org  Mon Dec  1 23:00:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:18 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
 <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
 <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>
Message-ID: <JnAk8zCDMAcaBHJLI-TjP-BNUm36jvfOLOSujnac76A=.7e7d5000-db35-401a-b722-179945803027@github.com>

On Mon, 1 Dec 2025 18:52:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition.
>
> So why do you need one in java_lang_Thread then?

It's needed for the `disable_transition_for_one` case. We only want to disable transitions for that particular vthread (yes, we could also disable transitions for all JavaThreads but that would be unnecessary).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2579002237

From ysuenaga at openjdk.org  Mon Dec  1 23:38:22 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 1 Dec 2025 23:38:22 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v3]
In-Reply-To: <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
Message-ID: <IC4Svr32G_dhzQng-l9KgUEjeME82-eILLcxZO-Y28A=.69668d8f-ed61-425e-9fe8-fe85ffb3bcec@github.com>

On Thu, 20 Nov 2025 01:25:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for macOS

Thanks a lot for your review!
I applied the suggestion from Chris, and it made new commit. So could you approve this PR again? @pchilano @plummercj

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3599434899

From ysuenaga at openjdk.org  Mon Dec  1 23:38:20 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 1 Dec 2025 23:38:20 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v4]
In-Reply-To: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
Message-ID: <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>

> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
> 
> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
> 
> Big thanks to @pchilano for your help!

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
  
  Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28284/files
  - new: https://git.openjdk.org/jdk/pull/28284/files/bb2fe02f..0b7c187a

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

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

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

From coleenp at openjdk.org  Tue Dec  2 00:10:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 00:10:26 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Additional comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/7f234078..8861381f

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

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

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

From cjplummer at openjdk.org  Tue Dec  2 00:36:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Dec 2025 00:36:53 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v4]
In-Reply-To: <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
Message-ID: <qQ2C3jrzhNVau6asAs9y9wKcihCZf-6ljvAyDSxe-dk=.14e66d15-485f-4751-bd8d-24b00da5007a@github.com>

On Mon, 1 Dec 2025 23:38:20 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28284#pullrequestreview-3527640187

From duke at openjdk.org  Tue Dec  2 00:55:59 2025
From: duke at openjdk.org (Larry Cable)
Date: Tue, 2 Dec 2025 00:55:59 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
Message-ID: <WeQWR7Toz2cVgFAHBGgPdqbXiDFBNWP3hOf3ZvXIt5c=.13f14b38-4944-44ff-bb70-1f3116bd6ce4@github.com>

On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

we need someone with reviewer status to approve this for integration

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3599624713

From sspitsyn at openjdk.org  Tue Dec  2 02:17:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 02:17:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
Message-ID: <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>

On Tue, 2 Dec 2025 00:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comment

Looks good. Posted one nit comment though.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67:

> 65:   public long     getAccessFlags()      { return            accessFlags.getValue(this);  }
> 66:   // Convenience routine
> 67:   public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags());      }

Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527876434
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579353928

From dlong at openjdk.org  Tue Dec  2 04:47:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 04:47:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
 <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>
Message-ID: <EwZ9R5afHHB6NGVbKNQqUwu4VQR2SphDB9hZXYrMigI=.dcc5b892-dcb4-4c34-a17d-0c30802c4dff@github.com>

On Mon, 1 Dec 2025 22:53:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 4104:
>> 
>>> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
>>> 4103:     }
>>> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.
>> 
>> In other words, we are accessing subtype-specific information, so we need to determine the subtype first.
>
> I can add this to the comment if you think it's helpful.

Yes, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579562880

From dlong at openjdk.org  Tue Dec  2 04:55:50 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 04:55:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
 <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>
Message-ID: <41lDi_gRckFIB_TJ2FJb6HdB_vc2_0Jj0WKsLfTyLGY=.e8ed7a8f-df9a-48c1-abba-e25fdcb3c333@github.com>

On Mon, 1 Dec 2025 22:48:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 237:
>> 
>>> 235: 
>>> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
>>> 237:   InstanceKlassFlags _misc_flags;
>> 
>> It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:
>> 
>> InstanceKlassFlags _misc_flags; // contains _reference_type
>> AccessFlags        _access_flags;
>> char _reserved[2];
>
> ClassState is a u1 so that fills the u2 gap with reference_type.  So I don't think moving reference type will help.

You're right, I missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579576187

From dholmes at openjdk.org  Tue Dec  2 06:24:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 06:24:07 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
Message-ID: <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

Nothing further from me. Again a great piece of work!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3528335950

From sspitsyn at openjdk.org  Tue Dec  2 06:51:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 06:51:47 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v2]
In-Reply-To: <9QjsUpQDfW9h9YLwAn8ks2nUD5PfF7nfY8nx7zmvpOs=.fcc2ecc1-f97e-4fd2-b069-57c89bf00ed4@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>
 <N7b7ttWwmLt8bJ1vNYujmYfFopZssgyB55FNoO5DbuY=.93a7d7d4-88d7-4632-b9ae-2a429936eec3@github.com>
 <wuqaPXbGCCYwSv051DmgZ3hHozeIvMgj1yN8a91y378=.b2670ffd-9b81-4320-be80-592fb8272b38@github.com>
 <9QjsUpQDfW9h9YLwAn8ks2nUD5PfF7nfY8nx7zmvpOs=.fcc2ecc1-f97e-4fd2-b069-57c89bf00ed4@github.com>
Message-ID: <qDzUbm8gRC4gj6QDfZl5hP2bxCNfKHVAQwCe2hUP384=.8913d1d4-a0a9-49af-b29f-1a23d8166a6b@github.com>

On Mon, 1 Dec 2025 21:43:10 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> How about virtualThreadStartEventsEnabledForDeferredEventMode?

Agree with Alex, long but cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2579844344

From sspitsyn at openjdk.org  Tue Dec  2 06:51:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 06:51:50 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v2]
In-Reply-To: <QU2EH_9bwcW2X6BvdnsRL6APgfON7tX-0ZvIz_v0bN8=.748c2f13-a232-4fb9-8502-32debd4f14e5@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <QU2EH_9bwcW2X6BvdnsRL6APgfON7tX-0ZvIz_v0bN8=.748c2f13-a232-4fb9-8502-32debd4f14e5@github.com>
Message-ID: <DuLo-cTq6BMRaQfntbDEoOwczu3n9d0M76xH42rBELg=.f67f69d9-51b5-41fe-af57-c4ecbf70c484@github.com>

On Thu, 27 Nov 2025 01:36:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
>> 
>> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
>> 
>> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use EventIndex type

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1321:

> 1319:             if (node != NULL) {
> 1320:                 // This means the vthread has terminated already. This can only happen
> 1321:                 // with vthreads since VIRTUAL_THREAD_END events might not be enable to

Nit: s/might not be enable/might not be enabled/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2579587185

From sspitsyn at openjdk.org  Tue Dec  2 08:21:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 08:21:57 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
Message-ID: <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88:

> 86:         // We rebinded on start_transition but the mount/unmount operation
> 87:         // failed so now we need to rebind to the original state.
> 88:         _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj());

Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2580118016

From dholmes at openjdk.org  Tue Dec  2 09:34:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 09:34:14 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <SvNSsJ64K8NIilNRs9MS6IWcc4ExSDtM6QJzJ37MzF4=.f08fd1b8-d844-48ec-9426-13c8b08e1dc8@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

Thanks for the updates. Seems reasonable.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3529119616

From dholmes at openjdk.org  Tue Dec  2 09:45:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 09:45:52 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <f1AHD2_Xm4iM_Td7ni2DD5DkdhBZikV99of32f19esg=.51084d4b-35be-4a18-bbcd-bdb2fd9253de@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
 <KirCw5YLLWb0Z-9u_PnWwCvljG1gGde6g46dGSGJnas=.0d3671a4-8d72-4ad9-ac2b-5827e90a116d@github.com>
 <qkOeQflSqilCpMaITnGJ_I-p6eUqypvmTkcX9Q_LO4c=.e3ff4276-140b-4a5c-888a-24e34b45adca@github.com>
 <f1AHD2_Xm4iM_Td7ni2DD5DkdhBZikV99of32f19esg=.51084d4b-35be-4a18-bbcd-bdb2fd9253de@github.com>
Message-ID: <2Pa32ipOuPa9thyQvPlXQ5AZi34kbxs_SPGlivudyA8=.865ecd6f-891b-49a4-b472-2f663e186e58@github.com>

On Wed, 29 Oct 2025 23:29:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert.
>
>> @sspitsyn and @sercher I'll take a look since I familiar with the code and the platform...
> 
> Okay. Thank you, Larry!

We need two reviewers. It doesn't look like @sspitsyn got to this and I am unsure what @larry-cable 's view is.

The PR also needs to be refreshed as so much time has passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3601126930

From aartemov at openjdk.org  Tue Dec  2 10:28:16 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 2 Dec 2025 10:28:16 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v19]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <vTPwrfr1lZzWyrRcdQm4K5G1EZfZ7B-U0fqc6g2tCvg=.93a9eb62-7f0c-4fc0-87c5-bea601874dde@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Fixed semi-broken tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/8283d9c0..d45fc76b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=17-18

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

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

From ysuenaga at openjdk.org  Tue Dec  2 12:23:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 2 Dec 2025 12:23:06 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v4]
In-Reply-To: <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
Message-ID: <Brej2uV-hbOjRzptCoZZD-RNu9FHEokigB71VA6-mrM=.06315776-be19-469c-9bcb-6881654cd8e9@github.com>

On Mon, 1 Dec 2025 23:38:20 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

Thanks a lot for your review & help!

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3601753651

From ysuenaga at openjdk.org  Tue Dec  2 12:23:07 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 2 Dec 2025 12:23:07 GMT
Subject: Integrated: 8371194:
 serviceability/sa/TestJhsdbJstackMixedWithXComp.java failing
In-Reply-To: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
Message-ID: <0RFxDYSFDzyMHdGRE6ci70bPbPUDBKHZXfeh4MWWFVk=.eef6e5fb-4b4d-4a84-9c07-ab16342366f7@github.com>

On Thu, 13 Nov 2025 08:15:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
> 
> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
> 
> Big thanks to @pchilano for your help!

This pull request has now been integrated.

Changeset: d3083ac0
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3083ac05453c9dd303038f90ddab50d52124e51
Stats:     298 lines in 12 files changed: 165 ins; 45 del; 88 mod

8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java failing

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Reviewed-by: cjplummer, pchilanomate

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

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

From coleenp at openjdk.org  Tue Dec  2 13:24:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 13:24:54 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fixed indentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/8861381f..c7247c00

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

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

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

From coleenp at openjdk.org  Tue Dec  2 13:24:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 13:24:55 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
 <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>
Message-ID: <DgOSKymKP3gcLF_nI96qtCq2CFXBiaS6aQn4kehVdYA=.d1bf8b4e-36aa-43cf-97cd-c8d605f1bd94@github.com>

On Tue, 2 Dec 2025 02:14:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional comment
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67:
> 
>> 65:   public long     getAccessFlags()      { return            accessFlags.getValue(this);  }
>> 66:   // Convenience routine
>> 67:   public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags());      }
> 
> Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`.

Thanks for noticing this. Did look messy.  I fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2581151367

From schernyshev at openjdk.org  Tue Dec  2 15:46:10 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 15:46:10 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v7]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <QqvcSaybgcaixurcVNvXw-Ec89gAd9cDYydeTBSvqX4=.89f9190c-e93a-4611-9f6e-097da4312fb5@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The...

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

 - Merge branch 'master' into JDK-8319589
 - Merge branch 'master' into JDK-8319589
 - Removed unused native method
 - addressed review comment #2
 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - addressed review comments
 - 8319589: Attach from root to a user java process not supported in Mac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/75dd6fb8..8118017f

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

  Stats: 391287 lines in 4297 files changed: 249688 ins; 89814 del; 51785 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

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

From larry.cable at oracle.com  Tue Dec  2 15:47:27 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Tue, 2 Dec 2025 07:47:27 -0800
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <2Pa32ipOuPa9thyQvPlXQ5AZi34kbxs_SPGlivudyA8=.865ecd6f-891b-49a4-b472-2f663e186e58@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
 <KirCw5YLLWb0Z-9u_PnWwCvljG1gGde6g46dGSGJnas=.0d3671a4-8d72-4ad9-ac2b-5827e90a116d@github.com>
 <qkOeQflSqilCpMaITnGJ_I-p6eUqypvmTkcX9Q_LO4c=.e3ff4276-140b-4a5c-888a-24e34b45adca@github.com>
 <f1AHD2_Xm4iM_Td7ni2DD5DkdhBZikV99of32f19esg=.51084d4b-35be-4a18-bbcd-bdb2fd9253de@github.com>
 <2Pa32ipOuPa9thyQvPlXQ5AZi34kbxs_SPGlivudyA8=.865ecd6f-891b-49a4-b472-2f663e186e58@github.com>
Message-ID: <7fc0631a-ae51-4df2-bc7c-39369b5d6593@oracle.com>

I approve but I am not a reviewer :(

On 12/2/25 1:45 AM, David Holmes wrote:
> On Wed, 29 Oct 2025 23:29:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>
>>> @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert.
>>> @sspitsyn and @sercher I'll take a look since I familiar with the code and the platform...
>> Okay. Thank you, Larry!
> We need two reviewers. It doesn't look like @sspitsyn got to this and I am unsure what @larry-cable 's view is.
>
> The PR also needs to be refreshed as so much time has passed.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3601126930


From liach at openjdk.org  Tue Dec  2 17:17:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 17:17:44 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

src/hotspot/share/classfile/javaClasses.cpp line 1096:

> 1094:   // Set the raw access_flags, this is used by reflection instead of modifier flags.
> 1095:   // The Java code for array classes gets the access flags from the element type.
> 1096:   set_raw_access_flags(mirror(), k->is_array_klass() ? 0 : InstanceKlass::cast(k)->access_flags().as_unsigned_short());

Should we merge this is_array_klass() query with the main if-else block below? We can probably skip setting raw access flags for array classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578581321

From sspitsyn at openjdk.org  Tue Dec  2 19:23:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 19:23:36 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
Message-ID: <jIkEaDMteTFFqiLzQZf0oYVca3qbQINS-ajPn_Zb500=.288bc4d3-e0ad-4d65-882f-1ed3fe6968e8@github.com>

On Tue, 2 Dec 2025 13:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation.

Marked as reviewed by sspitsyn (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 101:

> 99:     }
> 100:     headerSize           = type.getSize();
> 101:     accessFlags  = new CIntField(type.getCIntegerField("_access_flags"), 0);

Nit: Not a big deal but this line also does not have proper indent. You can ignore this comment though. :)

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

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3531778810
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2582521355

From dholmes at openjdk.org  Tue Dec  2 19:49:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 19:49:41 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <WeQWR7Toz2cVgFAHBGgPdqbXiDFBNWP3hOf3ZvXIt5c=.13f14b38-4944-44ff-bb70-1f3116bd6ce4@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
 <WeQWR7Toz2cVgFAHBGgPdqbXiDFBNWP3hOf3ZvXIt5c=.13f14b38-4944-44ff-bb70-1f3116bd6ce4@github.com>
Message-ID: <MWKR7MTmkHoCg24rueZlTz3wPiYsymNQ0u1D4CGkFp8=.12534893-10b2-4313-9a25-5e3a51df3cb3@github.com>

On Tue, 2 Dec 2025 00:53:15 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8319589
>>  - Removed unused native method
>>  - addressed review comment #2
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - addressed review comments
>>  - 8319589: Attach from root to a user java process not supported in Mac
>
> we need someone with reviewer status to approve this for integration

@larry-cable  you can still "review" via the PR, rather than just email.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3603697996

From serb at openjdk.org  Tue Dec  2 20:09:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 20:09:57 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <_m-3bjxRDcMxOBa8umyAmvqWzz7VZYMZ8RKVwtaoWPU=.91da4b9b-84b0-47ff-9bf3-93c07dcfd79d@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3531919314

From mbaesken at openjdk.org  Tue Dec  2 20:09:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 2 Dec 2025 20:09:59 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
 <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
Message-ID: <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>

On Wed, 26 Nov 2025 11:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I'll run UI the tests for this.

Are there some (hopefully good) results from your runs ? 
Would prefer to get some feedback from you before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3596355336

From serb at openjdk.org  Tue Dec  2 20:10:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 20:10:00 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
 <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
 <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>
Message-ID: <ingxF5gHqbgOHmv9Va3Kbmcalz9CluE5PhVqv2lhFdM=.8c93a7de-9f05-422f-b218-954c9d2ab603@github.com>

On Mon, 1 Dec 2025 12:39:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Are there some (hopefully good) results from your runs ? Would prefer to get some feedback from you before integrating.

I did not find any issues in the jtreg desktop tests (headful/headless).

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3603763411

From pchilanomate at openjdk.org  Tue Dec  2 20:12:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:47 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

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

 - Merge branch 'master' into JDK-8364343
 - rebind in end_transition only for mount case
 - Fix comment in inline_native_vthread_start_transition
 - missing to initialize _is_disabler_at_start
 - More changes from Coleen's review
 - Drop VTMS from names
 - keep preexisting rebind order for mount
 - Remove INCLUDE_JVMTI macro
 - David's comments
 - Rename VM methods for endFirstTransition/startFinalTransition
 - ... and 3 more: https://git.openjdk.org/jdk/compare/836ae793...1f1cd594

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/44af0ca9..1f1cd594

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

  Stats: 84290 lines in 1350 files changed: 54871 ins; 20868 del; 8551 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From pchilanomate at openjdk.org  Tue Dec  2 20:12:49 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
Message-ID: <PP54KIhtKoCuuWU8YMqeEzY-p2NK8sI_6cUuGfE7-II=.2aa2a463-aba8-460b-b1eb-97d179e69ec7@github.com>

On Tue, 2 Dec 2025 06:20:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me. Again a great piece of work!
> 
> Thanks
>
Thanks for the review David!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603774217

From pchilanomate at openjdk.org  Tue Dec  2 20:20:32 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:32 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
 <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
 <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
Message-ID: <X2XiyWz5DzOg4pXBxrYeCA_f2V3WNM2Rn58dZRhUOuw=.43b6aa7c-6533-49ce-adc6-93c6e397ed8f@github.com>

On Mon, 1 Dec 2025 19:46:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.
>
> Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and  startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think.

Sounds good, filed https://bugs.openjdk.org/browse/JDK-8372953.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582659743

From pchilanomate at openjdk.org  Tue Dec  2 20:20:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
Message-ID: <5iEOi2ZO_ZVQbanlfWXhjIyGMQvZ4rt09LIK9YP-bgg=.5d15e13d-81cc-4843-bdb2-244841949808@github.com>

On Tue, 2 Dec 2025 08:15:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in inline_native_vthread_start_transition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88:
> 
>> 86:         // We rebinded on start_transition but the mount/unmount operation
>> 87:         // failed so now we need to rebind to the original state.
>> 88:         _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj());
> 
> Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction.

Yes, well spotted. I changed it to rebind the state only for the mount case, as in current code. This already handles a successful mount or a failed unmount. I also added and assert to verify we rebinded to the correct identity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582654454

From sspitsyn at openjdk.org  Tue Dec  2 20:31:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 20:31:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
Message-ID: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>

On Tue, 2 Dec 2025 20:12:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - David's comments
>  - Rename VM methods for endFirstTransition/startFinalTransition
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4b22489c...1f1cd594

Marked as reviewed by sspitsyn (Reviewer).

Yes, this is a great work!

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87:

> 85:       }
> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");

Nit: Thank you for update! This check can be simplified with:

      assert(_is_mount == is_virtual), "wrong identity");

But it becomes more obscure though. Feel free to ignore this comment.

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3531985682
PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603842122
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582681780

From cjplummer at openjdk.org  Tue Dec  2 20:32:20 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Dec 2025 20:32:20 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3531993784

From pchilanomate at openjdk.org  Tue Dec  2 20:42:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:29 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v12]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

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

  simplify assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/1f1cd594..7ffbbc6d

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

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

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

From pchilanomate at openjdk.org  Tue Dec  2 20:42:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
 <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
Message-ID: <AC_Jcyka6ot70oBXchaghxIeJq6jkvCY2t_DIMiXEI8=.dbfa623b-0aaf-48ae-a7e4-9d1e6b4ec28a@github.com>

On Tue, 2 Dec 2025 20:28:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Yes, this is a great work!
>
Thanks for the review Serguei!

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87:
> 
>> 85:       }
>> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
>> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");
> 
> Nit: Thank you for update! This check can be simplified with:
> 
>       assert(_is_mount == is_virtual), "wrong identity");
> 
> But it becomes more obscure though. Feel free to ignore this comment.

I applied the suggestion, it reads well to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603874550
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582710357

From amenkov at openjdk.org  Tue Dec  2 20:46:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 20:46:35 GMT
Subject: RFR: 8372809: Test
 vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
References: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
Message-ID: <ue99LODsnLJZDd2pg0LJb8QDYlfovy7A1AUxOfpJmT4=.9252d179-bc2c-4661-83d2-22449da201d6@github.com>

On Mon, 1 Dec 2025 21:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix a couple of asserts that are now being triggered after the changes for [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) were introduced. I had already run into these asserts while working on [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380), and had already fixed them there. However, [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380) likely is not going to be pushed for JDK 26, so I have moved the fixes to this PR.
> 
> You can also find the fixes I moved over from [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) here: https://github.com/openjdk/jdk/pull/28485/files#diff-65eb4035b1d9bb5ceaab430461cd782069fe88c0a7d0438964c041caf0aa5eec
> 
> Tested by running failed test case a few hundred times, and also all tier5 CI svc tests, which includes a lot of JDI related testing with virtual threads enabled. Also ran tier1 CI.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28587#pullrequestreview-3532036041

From cjplummer at openjdk.org  Tue Dec  2 20:49:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Dec 2025 20:49:00 GMT
Subject: RFR: 8372957: After JDK-8282441 JDWP might allow some invalid FrameIDs
 to be used
Message-ID: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>

[JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.

Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

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

Commit messages:
 - Don't free ThreadNodes that have generated FrameIDs.

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

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

From cjplummer at openjdk.org  Tue Dec  2 20:49:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Dec 2025 20:49:00 GMT
Subject: RFR: 8372957: After JDK-8282441 JDWP might allow some invalid
 FrameIDs to be used
In-Reply-To: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
References: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
Message-ID: <MeCkCVonDIGDhY09f1jFb3oKtPaf3qCegE3JwrfFIts=.0e19f97d-8f2d-48a9-b993-34b2d02fb8ee@github.com>

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

frameGeneration is used to generate FrameIDs for the thread. FrameIDs are used for accessing stack frame contents. For example StackFrame.GetValues. The FrameID is generated by ThreadReference.Frames, with each frame in the returned array having a unique FrameID that is composed of the stack depth of the frame combined with the thread's current frameGeneration value. When a FrameID is passed to the debug agent, it validates that the frameGeneration in the FrameID is equal to the thread's current frameGeneration value. frameGeneration is incremented each time the thread is resumed, effectively invalidating any FrameIDs already generated for the thread.

Currently frameGeneration is ignored when deciding if a ThreadNode can be freed. This means if the ThreadNode is recreated later on, frameGeneration will return to its default of 0, possibly allowing stale FrameIDs to become valid again.

At first I was thinking I need to retain ThreadNodes whenever frameGeneration is incremented. That is both overkill and not enough at the same time. It is overkill because for any thread that has a resume done on it, we would need to retain the ThreadNode even if there are no FrameIDs generated for it. It is also not enough because if frameGeneration is 0 and there was a FrameID generated using it, and a VM.Resume is done while the ThreadNode is not allocated, the FrameID should become invalid at that point but it won't because there is no ThreadNode to increment frameGeneration on.

The better solution here is to set a flag on the ThreadNode whenever a FrameID is created for the thread. This is far less common than doing resumes, and should still allow for most ThreadNodes to be freed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28616#issuecomment-3603881146

From lmesnik at openjdk.org  Tue Dec  2 21:09:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 21:09:11 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:

 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update src/hotspot/share/runtime/javaThread.hpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update src/hotspot/share/runtime/javaThread.cpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/f7e869b2..aaa0ccbb

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

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

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

From amenkov at openjdk.org  Tue Dec  2 21:09:16 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:09:16 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
Message-ID: <ytRtbZRc4hBLmCHeVFi8aQeuUWg3DLyVetsRM7GnuE8=.3ff8b1cb-fb4a-4ffb-ad7b-1d8a7b384aab@github.com>

On Fri, 28 Nov 2025 21:09:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made jvmti_events_disalber as counter

src/hotspot/share/runtime/javaThread.cpp line 454:

> 452:   _is_disable_suspend(false),
> 453:   _is_in_java_upcall(false),
> 454:   _jvmti_events_disabled(false),

Suggestion:

  _jvmti_events_disabled(0),

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

> 766:   // - JVMTI is making a Java upcall (_is_in_java_upcall)
> 767:   bool should_hide_jvmti_events() const          { return _is_in_VTMS_transition || _is_disable_suspend
> 768:     || _is_in_java_upcall || _jvmti_events_disabled != 0; }

Suggestion:

  bool should_hide_jvmti_events() const {
    return _is_in_VTMS_transition || _is_disable_suspend || _is_in_java_upcall || _jvmti_events_disabled != 0;
  }

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @summary  Test verify that object allocation sampling is disabled during AOT.

Suggestion:

 * @summary The test verifies that object allocation sampling is disabled during AOT.

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 26:

> 24: #include "jvmti.h"
> 25: #include "jvmti_common.hpp"
> 26: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 34:

> 32:   LOG("Sampled object\n");
> 33: }
> 34: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 49:

> 47:     return JNI_ERR;
> 48:   }
> 49: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 67:

> 65:   err = jvmti->SetHeapSamplingInterval(10);
> 66:   check_jvmti_error(err, "SetHeapSamplingInterval");
> 67: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582743429
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582750762
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582754970
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582755827
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582756365
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582756981
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582759498

From amenkov at openjdk.org  Tue Dec  2 21:14:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:14:33 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <u2bI6YRr6_GlR87NRPXb2yunNGdgJN5g9oLy7M6ETb4=.ed20abe4-3c0f-4a87-8eac-8822f09e862c@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3532124536

From sspitsyn at openjdk.org  Tue Dec  2 21:22:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 21:22:12 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v12]
In-Reply-To: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
Message-ID: <fPa-U_4A3CzC8YNAyCALLvAZNeIcQkc_2sasnhcCAgs=.d0dd726a-411c-4547-9062-86650c7113cf@github.com>

On Tue, 2 Dec 2025 20:42:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify assert

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3532150956

From amenkov at openjdk.org  Tue Dec  2 21:24:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:24:53 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
Message-ID: <4-yIaDJAERF9W6jzvgKZ-iqTf27YogFBsLBxb-K86Fw=.15960f7b-f507-4425-b260-f8d148afda9b@github.com>

On Tue, 2 Dec 2025 21:09:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.hpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532157793

From amenkov at openjdk.org  Tue Dec  2 21:31:30 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:31:30 GMT
Subject: RFR: 8372957: After JDK-8282441 JDWP might allow some invalid
 FrameIDs to be used
In-Reply-To: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
References: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
Message-ID: <Cax_sMByUz0WOZAErSJEVkDR_fwgTsNZ1moLbiNNJ3E=.039809e6-3a2b-4a83-9c9b-c4a97235e437@github.com>

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28616#pullrequestreview-3532177536

From sspitsyn at openjdk.org  Tue Dec  2 22:04:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:04:45 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
Message-ID: <9ZbaqmcinlEmgQkJm9ardDAIC5SeoWfBb0BCgfsTPO4=.57f7effb-cc59-41b2-860c-f536d27653c2@github.com>

On Tue, 2 Dec 2025 21:09:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.hpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

The fix looks good in general. I've requested a minor test update though.

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 32:

> 30: SampledObjectAlloc(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread, jobject object, jclass object_klass, jlong size) {
> 31:   LOG("Sampled object\n");
> 32: }

I'd suggest to increment a counter here. Then check it at the end and fail if it is not 0.

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532263502
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582904026

From sspitsyn at openjdk.org  Tue Dec  2 22:11:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:11:30 GMT
Subject: RFR: 8372809: Test
 vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
References: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
Message-ID: <1ggmKcb1c8WlFcYOrb0lTY3_iAgBKSQmDnyPfpaH9yo=.c447d38c-dd49-4e16-8b48-724ff68fc449@github.com>

On Mon, 1 Dec 2025 21:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix a couple of asserts that are now being triggered after the changes for [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) were introduced. I had already run into these asserts while working on [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380), and had already fixed them there. However, [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380) likely is not going to be pushed for JDK 26, so I have moved the fixes to this PR.
> 
> You can also find the fixes I moved over from [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) here: https://github.com/openjdk/jdk/pull/28485/files#diff-65eb4035b1d9bb5ceaab430461cd782069fe88c0a7d0438964c041caf0aa5eec
> 
> Tested by running failed test case a few hundred times, and also all tier5 CI svc tests, which includes a lot of JDI related testing with virtual threads enabled. Also ran tier1 CI.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28587#pullrequestreview-3532295677

From sspitsyn at openjdk.org  Tue Dec  2 22:16:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:16:35 GMT
Subject: RFR: 8372957: After JDK-8282441 JDWP might allow some invalid
 FrameIDs to be used
In-Reply-To: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
References: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
Message-ID: <px9u3otCzxO73wRHiiFpUzc524-w3s_lkOXNlWCoWBY=.1121f5e6-0c02-400d-8291-69e45fa3cbfd@github.com>

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28616#pullrequestreview-3532310308

From sspitsyn at openjdk.org  Tue Dec  2 22:19:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:19:26 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <o7oNu_Qqm_wqIt1zzSpui2uKC1MYbAhQKs6stlNs9TQ=.9d26b0b9-bb65-4596-b458-8bb17143c2c7@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3532317632

From lmesnik at openjdk.org  Tue Dec  2 22:28:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:28:00 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
 <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>
Message-ID: <M7I565o0FefgrsX2DXWP3w1NkJN8RnJYXvrG5T2gplY=.bc92090f-8ba8-4328-a145-e40071d25548@github.com>

On Tue, 2 Dec 2025 20:29:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The issue reproduced by running test 
>> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
>> with `-XX:+CheckUnhandledOops`.
>> 
>> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
>> 
>> Testing with tier1-5.
>
> Looks good.

@plummercj, @alexmenkov, @sspitsyn Thank you for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28500#issuecomment-3604212792

From lmesnik at openjdk.org  Tue Dec  2 22:31:17 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:31:17 GMT
Subject: Integrated: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <VWlVGpCxt4kkYhDUngWIMahFTYytc4m-NgmltTJzWFE=.9b79c41f-2fc7-4ec0-8f5a-98d3d6a98c44@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

This pull request has now been integrated.

Changeset: b0a758f2
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0a758f2180a8305c05e9640192818bbb31d7922
Stats:     10 lines in 1 file changed: 5 ins; 4 del; 1 mod

8372552: unhandled oop in the JvmtiEventController::set_user_enabled

Reviewed-by: cjplummer, amenkov, sspitsyn

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

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

From lmesnik at openjdk.org  Tue Dec  2 22:37:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:37:22 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v6]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  extended testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/aaa0ccbb..830b5f94

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

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

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

From sspitsyn at openjdk.org  Tue Dec  2 23:15:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 23:15:49 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v6]
In-Reply-To: <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>
Message-ID: <KrTCcVRt0x9ZUEH5wCVa6H1ftFicFhNZ7cT2SyXCoHU=.4059ab70-0af9-4948-874f-52675e73d755@github.com>

On Tue, 2 Dec 2025 22:37:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extended testing

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532435540

From lmesnik at openjdk.org  Tue Dec  2 23:51:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 23:51:28 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <pZ9i5b1FUOCZkZY-gn97BhwvAWetUBbAMe7lHYA8uRY=.e8292b29-a6c1-492e-85a5-911288e12cd5@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
 <pZ9i5b1FUOCZkZY-gn97BhwvAWetUBbAMe7lHYA8uRY=.e8292b29-a6c1-492e-85a5-911288e12cd5@github.com>
Message-ID: <P49b4xriJxDScFkPU8hsiQLERVwG_i11rGWyvLRodFw=.4b04c12e-492e-48dc-b638-ef4236927bea@github.com>

On Fri, 28 Nov 2025 22:48:10 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   made jvmti_events_disalber as counter
>
> Looks good.

@fisk, @alexmenkov, @sspitsyn Thank you for review and provided feedback

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

PR Comment: https://git.openjdk.org/jdk/pull/28544#issuecomment-3604418038

From lmesnik at openjdk.org  Tue Dec  2 23:51:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 23:51:31 GMT
Subject: Integrated: 8372039: post_sampled_object_alloc is called while lock is
 handled
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <tLN6QSBu89eRQdkiawfemonxZxijlU9zLvrCRZ-DRRA=.885b948b-d60d-419e-abda-305e775dbd23@github.com>

On Thu, 27 Nov 2025 20:12:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

This pull request has now been integrated.

Changeset: f5e4cd7f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564
Stats:     194 lines in 8 files changed: 150 ins; 30 del; 14 mod

8372039: post_sampled_object_alloc is called while lock is handled

Reviewed-by: sspitsyn, eosterlund, amenkov

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

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

From sspitsyn at openjdk.org  Wed Dec  3 03:31:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 03:31:09 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v7]
In-Reply-To: <QqvcSaybgcaixurcVNvXw-Ec89gAd9cDYydeTBSvqX4=.89f9190c-e93a-4611-9f6e-097da4312fb5@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <QqvcSaybgcaixurcVNvXw-Ec89gAd9cDYydeTBSvqX4=.89f9190c-e93a-4611-9f6e-097da4312fb5@github.com>
Message-ID: <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com>

On Tue, 2 Dec 2025 15:46:10 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319589
>  - Merge branch 'master' into JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

src/hotspot/os/bsd/os_bsd.cpp line 881:

> 879:     uid_t uid = get_process_uid(pid);
> 880:     return (uid != (uid_t)-1) ? os::Posix::is_root(uid) : false;
> 881: }

Nit:
 - missed dot at the end of comments at lines 864, 877
 - indent above has to be 2, not 4

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 78:

> 76:         // Then we attempt to find the socket file again.
> 77:         // In macOS the socket file is located in per-user temp directory.
> 78:         String tempDir = getTempDirFromPid(pid);

Nit: I'd suggest to rename it to `tempdir` to follow the local naming convention which prevails.

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 223:

> 221:     }
> 222: 
> 223:     private File createAttachFile(String dir, int pid) throws IOException {

Nit: I'd suggest to rename `dir` to `tmpdir` to keep it unified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583476499
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583485123
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583487596

From sspitsyn at openjdk.org  Wed Dec  3 03:31:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 03:31:12 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
Message-ID: <X-w-zCX3IWQ1v-i7VsU2wsw59zTHc7y7dO291IS_o-c=.e7df8824-342b-4561-bc39-ef2c15ecb312@github.com>

On Tue, 23 Sep 2025 02:40:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - addressed review comments
>
> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 31:
> 
>> 29: import com.sun.tools.attach.spi.AttachProvider;
>> 30: 
>> 31: import sun.jvmstat.PlatformSupport;
> 
> This is convenient but I'm not sure it is appropriate. Need the serviceability folk to comment.

This looks like an unexpected and undesired dependency. I'll consult with other serviceability guys to find out what is better here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583491666

From schernyshev at openjdk.org  Wed Dec  3 07:22:52 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 07:22:52 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac
In-Reply-To: <7fc0631a-ae51-4df2-bc7c-39369b5d6593@oracle.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7fc0631a-ae51-4df2-bc7c-39369b5d6593@oracle.com>
Message-ID: <iNCGQkVd1iK5E3NVRm1O_eriv9dlsdrf8v-NfZjbR7I=.941d66f9-dbe9-425e-aeaf-2987d6b57491@github.com>

On Tue, 2 Dec 2025 15:50:14 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> I approve but I am not a reviewer :(

Thanks you @larry-cable for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3605428925

From schernyshev at openjdk.org  Wed Dec  3 07:23:00 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 07:23:00 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v7]
In-Reply-To: <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <QqvcSaybgcaixurcVNvXw-Ec89gAd9cDYydeTBSvqX4=.89f9190c-e93a-4611-9f6e-097da4312fb5@github.com>
 <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com>
Message-ID: <pUIbM4M-RsCjwXen5sPIWZjjUYlVfPWw3s3g29BFvz0=.1bb79595-e1fb-4258-bf06-a088f69cc779@github.com>

On Wed, 3 Dec 2025 03:10:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8319589
>>  - Merge branch 'master' into JDK-8319589
>>  - Removed unused native method
>>  - addressed review comment #2
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - addressed review comments
>>  - 8319589: Attach from root to a user java process not supported in Mac
>
> src/hotspot/os/bsd/os_bsd.cpp line 881:
> 
>> 879:     uid_t uid = get_process_uid(pid);
>> 880:     return (uid != (uid_t)-1) ? os::Posix::is_root(uid) : false;
>> 881: }
> 
> Nit:
>  - missed dot at the end of comments at lines 864, 877
>  - indent above has to be 2, not 4

Thanks @sspitsyn , fixed.

> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 78:
> 
>> 76:         // Then we attempt to find the socket file again.
>> 77:         // In macOS the socket file is located in per-user temp directory.
>> 78:         String tempDir = getTempDirFromPid(pid);
> 
> Nit: I'd suggest to rename it to `tempdir` to follow the local naming convention which prevails.

Thanks! Fixed.

> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 223:
> 
>> 221:     }
>> 222: 
>> 223:     private File createAttachFile(String dir, int pid) throws IOException {
> 
> Nit: I'd suggest to rename `dir` to `tmpdir` to keep it unified.

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583859087
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583860448
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583860781

From schernyshev at openjdk.org  Wed Dec  3 07:22:51 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 07:22:51 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/8118017f..fd1645b0

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

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

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

From stuefe at openjdk.org  Wed Dec  3 07:29:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 3 Dec 2025 07:29:43 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
Message-ID: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>

_This patch is not intended for JDK 26_. 

I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.

This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.

For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].

This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.

### Implementation Notes

With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
  a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
  b) 64-bit, COH on
  c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.

I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).

I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
  
Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.

### Testing

- tier 1 2 3 locally on Linux x64
- SAP ran their whole set of tests for all the platforms they support.


[1] https://bugs.openjdk.org/browse/JDK-8350754
[2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html
[3] https://bugs.openjdk.org/browse/JDK-8363998

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

Commit messages:
 - Copyright fixes
 - Merge branch 'openjdk:master' into JDK-8363996-Obsolete-UseCompressedClassPointers
 - Review feedback
 - Fix after JDK-8372045
 - fix riscv build
 - fix TestVMConfigInHsErrFile
 - remove switch from global
 - fix aarch64 build
 - wip
 - close to finish
 - ... and 39 more: https://git.openjdk.org/jdk/compare/6f2169ff...64d7984a

Changes: https://git.openjdk.org/jdk/pull/28366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363996
  Stats: 1735 lines in 139 files changed: 64 ins; 1198 del; 473 mod
  Patch: https://git.openjdk.org/jdk/pull/28366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366

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

From duke at openjdk.org  Wed Dec  3 07:29:45 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 3 Dec 2025 07:29:45 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

These?comments probably?apply to?many?other locations:

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

But?the?changes should?probably be?done in?a?separate?PR, if?at?all.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4919:

> 4917:   } else {
> 4918:     ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes()));
> 4919:     decode_klass_not_null(dst);

The `decode_klass_not_null(dst)` call is?now?common to?all?branches, so?it?can be?moved outside:

if (UseCompactObjectHeaders) {
	load_narrow_klass_compact(dst, src);
} else {
	ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes()));
}
decode_klass_not_null(dst);

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998:

> 4996:     ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes()));
> 4997:     ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes()));
> 4998:     cmpw(tmp1, tmp2);

Same?here, but?with `cmpw(tmp1,?tmp2)`.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3484591668
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543442496
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543444838

From stuefe at openjdk.org  Wed Dec  3 07:29:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 3 Dec 2025 07:29:47 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>
Message-ID: <ZjHdtQxrx1jfYPKwpqEUfyZEkwZwUy3beLEEtDN7Fz4=.b110fae0-c345-4406-bda4-2823200deb43@github.com>

On Wed, 19 Nov 2025 20:22:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998:
> 
>> 4996:     ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes()));
>> 4997:     ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes()));
>> 4998:     cmpw(tmp1, tmp2);
> 
> Same?here, but?with `cmpw(tmp1,?tmp2)`.

I did your suggested changes, but will hold on doing similar changes (moving instructions out of now common branches) for now; I feel that this makes the diff less clear, and this PR will be annoying to review as it is; lots of onerous work. Let's hear what others think once I undrafted this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2581326249

From sspitsyn at openjdk.org  Wed Dec  3 07:31:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 07:31:12 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
Message-ID: <63PmCR3UqPLsAldxHCS78MZ7hViJqdvOg891j28uhww=.b571ab58-4b7f-413b-814e-e42ab8e7b010@github.com>

On Wed, 3 Dec 2025 07:22:51 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comments

This is a nice fix in general. Thank you for this work!
I hope to complete my review tomorrow with one more pass.
Question: How was this update tested? Do you have a jtreg test or you've done it manually?

src/hotspot/os/bsd/os_bsd.cpp line 956:

> 954: }
> 955: #endif
> 956: 

Nit: I'd suggest to get rid of empty lines which do not improve readability:
 890, 903, 908, 917, 923, 930, 933, 941, 944
 Also, the comment at line 931 is better to start with a capital letter: `// If the ..` .

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

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3533557192
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583937603

From mbaesken at openjdk.org  Wed Dec  3 08:09:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Dec 2025 08:09:12 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <jtI9qujDvqKs-Lva7WzXQbk_pXhsIdwWrMJjL-KTnFc=.5d4c0f2b-c205-4997-9285-19bae53dea0a@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Thanks for testing !

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3605564159

From mbaesken at openjdk.org  Wed Dec  3 08:09:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Dec 2025 08:09:13 GMT
Subject: Integrated: 8371893: [macOS] use dead_strip linker option to reduce
 binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <68YkLbtPCCMXMUfLNYA7pIL4eP7ZqOWno0eOeMo7W6s=.bf818f36-049f-4cb4-8ac0-d0b83776dec7@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

This pull request has now been integrated.

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

8371893: [macOS] use dead_strip linker option to reduce binary size

Reviewed-by: erikj, lucy, serb

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

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

From sspitsyn at openjdk.org  Wed Dec  3 08:44:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 08:44:50 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v6]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <enBp5r41RtxIz_QNIu2bh3Y4ZMxC46hcrEM1B1UXxdc=.ba77ca00-b28b-495e-9e0f-d627a4b3f2e2@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

  review: optimize hide_single_stepping and post_method_exit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/d82e4efe..bb4b11f9

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

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

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

From sspitsyn at openjdk.org  Wed Dec  3 08:50:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 08:50:03 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v7]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <U_9kRmJrY4s0NTSuTkzZctskhApUlSkJhbldVf1bZ3g=.5ea5a021-752a-4b1f-99c3-a1d193198291@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

 - Merge
 - review: optimize hide_single_stepping and post_method_exit
 - review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS
 - review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx)
 - review: fix typo in a EATests.java comment
 - cleanup: removed an old code fragment in frame.cpp
 - 6960970: Debugger very slow during stepping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/bb4b11f9..abb1950c

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

  Stats: 64652 lines in 1068 files changed: 42639 ins; 15493 del; 6520 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

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

From kevinw at openjdk.org  Wed Dec  3 10:05:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 10:05:30 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:

> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
> 77:    * specification of the corresponding JVM command-line options, please refer
> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.

One more late nit: these links have just the raw number in the link text. Better to have:

* to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2584438379

From cnorrbin at openjdk.org  Wed Dec  3 10:08:50 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 10:08:50 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <zDsykp-YyLiCkLehUHngSG-fLkyS3xk1DBm0XQGql6A=.bd8215b4-49fb-473a-8b34-02854bdaa8b9@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3606036558

From cnorrbin at openjdk.org  Wed Dec  3 10:08:51 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 10:08:51 GMT
Subject: Integrated: 8372615: Many container tests fail when running rootless
 on cgroup v1
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <tOoj-MIEKUKTnUIgsR9lC93aEbBGyI5TMlhszWcSkes=.8716b906-2f74-4d90-b7db-55855d23fd4a@github.com>

On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

This pull request has now been integrated.

Changeset: f1a4d1bf
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1a4d1bfde652cf758117b93bbd02ae8248e805e
Stats:     154 lines in 27 files changed: 29 ins; 71 del; 54 mod

8372615: Many container tests fail when running rootless on cgroup v1

Reviewed-by: sgehwolf, dholmes

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

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

From coleenp at openjdk.org  Wed Dec  3 13:17:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:45 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Take out ?: for array classes in set_raw_access_flags call.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/c7247c00..d311ded9

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

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

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

From coleenp at openjdk.org  Wed Dec  3 13:17:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:46 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
Message-ID: <ZTn7i92Naw3uYroLePr4QyMjBx5iV5hczjEw4ZF-VGM=.66162f0d-5770-4859-8602-05d3adf262e6@github.com>

On Tue, 2 Dec 2025 13:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation.

Thanks for reviewing Vladimir, Dean and Serguei, and review in progress Chen. I'm not planning to integrate this until JDK 27.

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

PR Comment: https://git.openjdk.org/jdk/pull/28371#issuecomment-3606802218

From coleenp at openjdk.org  Wed Dec  3 13:17:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:48 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>
Message-ID: <H6yqUYEyVUcIQYPwSrZltiNvYD1mc4m8YfVhTE-hWR8=.c0588fe4-7d2f-4157-b1b7-9e77f4381fa8@github.com>

On Mon, 1 Dec 2025 20:43:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1096:
> 
>> 1094:   // Set the raw access_flags, this is used by reflection instead of modifier flags.
>> 1095:   // The Java code for array classes gets the access flags from the element type.
>> 1096:   set_raw_access_flags(mirror(), k->is_array_klass() ? 0 : InstanceKlass::cast(k)->access_flags().as_unsigned_short());
> 
> Should we merge this is_array_klass() query with the main if-else block below? We can probably skip setting raw access flags for array classes.

Yes, that would be an improvement.  I'll still set them to zero (even though it can be elided), so that I can keep the comment for array types though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2585064578

From jsikstro at openjdk.org  Wed Dec  3 15:06:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 15:06:20 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no GC
Message-ID: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>

Hello,

 If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
 
Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.

Testing:
* Rerun 10 times with Serial and Parallel for each test and they all pass

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

Commit messages:
 - Spell fix
 - 8373022: Increase initial heap size for test which assumes no GC

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

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

From stefank at openjdk.org  Wed Dec  3 15:06:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 15:06:21 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <WLoRoZVDrdFlaelFu9NdxHeycPHFPIpu-b61J0YArF8=.157295c8-99d9-4262-a9a7-764335c7c5d9@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28637#pullrequestreview-3535483955

From pchilanomate at openjdk.org  Wed Dec  3 15:27:06 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 15:27:06 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8364343
 - simplify assert
 - Merge branch 'master' into JDK-8364343
 - rebind in end_transition only for mount case
 - Fix comment in inline_native_vthread_start_transition
 - missing to initialize _is_disabler_at_start
 - More changes from Coleen's review
 - Drop VTMS from names
 - keep preexisting rebind order for mount
 - Remove INCLUDE_JVMTI macro
 - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

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

Changes: https://git.openjdk.org/jdk/pull/28361/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=12
  Stats: 1957 lines in 41 files changed: 914 ins; 823 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From macarte at openjdk.org  Wed Dec  3 15:27:54 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 15:27:54 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <1xvBfNax6BA3eMN--W-IcfjlKVcMd_vJq9Gh9edqtmg=.a489f78b-6a8f-4ada-a6fc-87a667ad6a7d@github.com>

On Fri, 21 Nov 2025 11:50:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 45:
> 
>> 43: import jdk.test.lib.process.OutputAnalyzer;
>> 44: 
>> 45: public class HotSpotAOTCacheMXBeanTest {
> 
> In addition to testing the endRecording operation, we also need to test both the direct and indirect access to the MXBean. The test currently obtains a proxy with newPlatformMXBeanProxy (good) but the direct access with ManagementFactory.getPlatformMXBean is not tested right now.
> 
> Another thing to test is that getObjectName returns the expected object name.

Agreed and I will add these additional tests in a subsequent PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2585561932

From ayang at openjdk.org  Wed Dec  3 15:44:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 15:44:17 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <e8yS9gLHAzGarzcf6f01d4jy-5UvwO3e-ODJB0w0cJY=.250f60b2-91cd-4651-aad8-cb2d581299c1@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28637#pullrequestreview-3535677540

From cjplummer at openjdk.org  Wed Dec  3 16:24:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 16:24:09 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <hPLv6X41usUJ7OWWosmJ-4Kvmm_bDMiHCTGXFcDAxDE=.f9100304-8674-478f-8831-9ca356af7f13@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

Most of the SA tests probably have this requirement. What is it that made these two tests be noticed? Why was a small initial heap size being used?

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3607685544

From cjplummer at openjdk.org  Wed Dec  3 16:30:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 16:30:38 GMT
Subject: RFR: 8372809: Test
 vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
References: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
Message-ID: <Ix_aKYAQl8e8-TV6KPH0j4ndn2IqgG7usfElkTrTcUE=.af185676-e4fb-4b77-93e8-1d880589e97a@github.com>

On Mon, 1 Dec 2025 21:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix a couple of asserts that are now being triggered after the changes for [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) were introduced. I had already run into these asserts while working on [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380), and had already fixed them there. However, [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380) likely is not going to be pushed for JDK 26, so I have moved the fixes to this PR.
> 
> You can also find the fixes I moved over from [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) here: https://github.com/openjdk/jdk/pull/28485/files#diff-65eb4035b1d9bb5ceaab430461cd782069fe88c0a7d0438964c041caf0aa5eec
> 
> Tested by running failed test case a few hundred times, and also all tier5 CI svc tests, which includes a lot of JDI related testing with virtual threads enabled. Also ran tier1 CI.

Thank you for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28587#issuecomment-3607713388

From jsikstro at openjdk.org  Wed Dec  3 16:33:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 16:33:58 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <hPLv6X41usUJ7OWWosmJ-4Kvmm_bDMiHCTGXFcDAxDE=.f9100304-8674-478f-8831-9ca356af7f13@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <hPLv6X41usUJ7OWWosmJ-4Kvmm_bDMiHCTGXFcDAxDE=.f9100304-8674-478f-8831-9ca356af7f13@github.com>
Message-ID: <ENm5XgpkdZ_OTqvSmesCPDvZLyTnWDKHomRwyYoEUjE=.096b559b-0fbc-4e66-b265-a66279b201c1@github.com>

On Wed, 3 Dec 2025 16:21:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Most of the SA tests probably have this requirement. What is it that made these two tests be noticed? Why was a small initial heap size being used?

We've seen that these tests fail when changing the value of InitialRAMPercentage to 0, which results in a very small initial heap size. I'm about to add a few more tests which also needs to be run with a "non-small" initial heap size.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3607728357

From cjplummer at openjdk.org  Wed Dec  3 16:41:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 16:41:48 GMT
Subject: Integrated: 8372809: Test
 vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
References: <M570cAWqXoL9q-aZ5mG9aS_LAhCyYH-A_Nc-5AIYLdE=.eefdb901-99ca-40ee-9d32-d4d59ac0e4fb@github.com>
Message-ID: <kxwuFYxMqxqyUHXetzRYFc4p_JHvMkPaZe_ECyjgX_8=.3c35be0c-4c60-4d0f-b4fa-a4fcb6212f4e@github.com>

On Mon, 1 Dec 2025 21:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix a couple of asserts that are now being triggered after the changes for [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) were introduced. I had already run into these asserts while working on [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380), and had already fixed them there. However, [JDK-8371380](https://bugs.openjdk.org/browse/JDK-8371380) likely is not going to be pushed for JDK 26, so I have moved the fixes to this PR.
> 
> You can also find the fixes I moved over from [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) here: https://github.com/openjdk/jdk/pull/28485/files#diff-65eb4035b1d9bb5ceaab430461cd782069fe88c0a7d0438964c041caf0aa5eec
> 
> Tested by running failed test case a few hundred times, and also all tier5 CI svc tests, which includes a lot of JDI related testing with virtual threads enabled. Also ran tier1 CI.

This pull request has now been integrated.

Changeset: c4321503
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4321503976840f6630567c4fa430cd1ffca41fb
Stats:     18 lines in 1 file changed: 11 ins; 1 del; 6 mod

8372809: Test vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java failed: JVMTI_ERROR_THREAD_NOT_ALIVE

Reviewed-by: amenkov, sspitsyn

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

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

From cjplummer at openjdk.org  Wed Dec  3 16:45:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 16:45:21 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <-2gVJG09G3ER3zGMBJA7kbRsEOFzGMc32Qy7Hstw9lY=.8a29fb54-6083-4ee5-8248-f776b29d3102@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

It's probably just the timing of the GC that determines whether the initial small heap is a problem or not. If you want the SA tests to be reliable with something like InitialRAMPercentage=0, probably all of the tests should be updated. However, personally I don't think this type of fix should be necessary unless you feel testing in the manner is something we want to support. There are plenty of tests that start failing when non-standard command line options are used.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3607775022

From liach at openjdk.org  Wed Dec  3 16:46:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 16:46:44 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
Message-ID: <oivFNBHDut6vL19TEPdAv0Wh5-H63mpTOdnwogwOMT0=.87f3df38-2a52-4fdc-bc2d-1060a73efd16@github.com>

On Wed, 3 Dec 2025 13:17:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take out ?: for array classes in set_raw_access_flags call.

Thanks for this update!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3535989981

From cjplummer at openjdk.org  Wed Dec  3 17:14:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 17:14:39 GMT
Subject: RFR: 8372957: After JDK-8282441 JDWP might allow some invalid
 FrameIDs to be used
In-Reply-To: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
References: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
Message-ID: <41c3VrRVESaDxp4OvNgoKFaGqlHlXeqIkH3usROfQLw=.ceee4cdb-572c-4045-994f-648c24345b42@github.com>

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

Thank you for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28616#issuecomment-3607906897

From cjplummer at openjdk.org  Wed Dec  3 17:21:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 17:21:49 GMT
Subject: Integrated: 8372957: After JDK-8282441 JDWP might allow some invalid
 FrameIDs to be used
In-Reply-To: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
References: <7vJZuZlmg-dfKa0CMDkNopRVTdExR-einTKoqlwJnrM=.40388431-9c9e-4a88-8ed6-9bf8779c023c@github.com>
Message-ID: <Aq4uMwe3N0ZXsukzMXnwMm3z-dkKXpUtSG0fm6LKJBc=.7fcbd5bf-6333-4903-8405-db19db7a182c@github.com>

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

This pull request has now been integrated.

Changeset: 0bcef61a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bcef61a6de027c1b7e481e2115016ee961707a5
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8372957: After JDK-8282441 JDWP might allow some invalid FrameIDs to be used

Reviewed-by: amenkov, sspitsyn

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

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

From macarte at openjdk.org  Wed Dec  3 17:23:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 17:23:37 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v12]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Small doc change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/0086e0ec..6024cf2e

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

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

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

From coleenp at openjdk.org  Wed Dec  3 17:24:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 17:24:10 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
Message-ID: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>

On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8364343
>  - simplify assert
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

Still good! Maybe you should wait for the last three GHA actions to finish first

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3536145413

From macarte at openjdk.org  Wed Dec  3 18:05:39 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:39 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v13]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Removed superfluous library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6024cf2e..67400da9

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

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

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

From macarte at openjdk.org  Wed Dec  3 18:05:42 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:42 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <CN17j92gSz5UikhTYA9KE6oDSAk6o8b8Emkn4lLdPG4=.6d7d314a-f207-4bc8-bfc5-1d58dd5c6398@github.com>

On Fri, 21 Nov 2025 11:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 31:
> 
>> 29:  * @requires vm.cds.write.archived.java.heap
>> 30:  * @library /test/jdk/lib/testlibrary /test/lib
>> 31:  *          /test/hotspot/jtreg/runtime/cds/appcds/aotCache/test-classes
> 
> Is test-classes used?

Tested and removed, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586114349

From kevinw at openjdk.org  Wed Dec  3 18:15:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 18:15:13 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v13]
In-Reply-To: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
Message-ID: <mBqDaHJoy5Jh8wfuNbjXrJxhX9LEk_C2LuK0Z2a7cDU=.c17e4966-071f-4808-8095-f11b02b255c0@github.com>

On Wed, 3 Dec 2025 18:05:39 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed superfluous library

Looks good, thanks for the updates.
Would be great if you can get to the 4 vs 2 indent note from Alan.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536328651

From macarte at openjdk.org  Wed Dec  3 19:17:50 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:17:50 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v14]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <rTxyRGAykexX1pJvT-C9gdnzlox3PaV5HsWZUbd4tWk=.b8266a59-b1af-4c2f-9aef-461561d84ca2@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Fixed indent and spacing issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/67400da9..6cd920da

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

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

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

From cjplummer at openjdk.org  Wed Dec  3 19:32:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Dec 2025 19:32:35 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v3]
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <3hVQAqDL9tXcQctRSLz24NcbyIDSvpQE9Go6AB2N654=.26a51c48-6260-466c-a795-f0c102256206@github.com>

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - use EventIndex type
 - fix whitespace
 - disable VIRTUAL_THREAD_START adn VIRTUAL_THREAD_END unless needed

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

Changes: https://git.openjdk.org/jdk/pull/28485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28485&range=02
  Stats: 312 lines in 7 files changed: 253 ins; 36 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28485/head:pull/28485

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

From macarte at openjdk.org  Wed Dec  3 19:40:07 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:40:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
Message-ID: <ct5U7Bzb-43CkS0AZb_QuDzafz34vAVcF0F0nRpTXGw=.c3216144-d8b9-4159-bf9a-c054d31444d6@github.com>

On Fri, 21 Nov 2025 11:33:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 97:
> 
>> 95:    * successfully; {@code false} otherwise.
>> 96:    */
>> 97:    public boolean endRecording();
> 
> Minor nit is that we usually use 4-space rather than 2-space indent in the java sources. You might want to check the /** .. */ comments in a few of the files as they are misaligned in a few places.

fixed - thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586374138

From pchilanomate at openjdk.org  Wed Dec  3 20:01:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:01:11 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
 <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
Message-ID: <plvMeLzQ8ppJ9pZsbY18b-L6RBEIFapI3Ex3L71zQkY=.0b000a39-22f7-49c6-993b-4b5979f80f93@github.com>

On Wed, 3 Dec 2025 17:21:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Still good! Maybe you should wait for the last three GHA actions to finish first
>
Done now. Thanks for the re-review Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3608600548

From pchilanomate at openjdk.org  Wed Dec  3 20:04:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:04:36 GMT
Subject: Integrated: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <R7yo6-n9jaF5YwNegJZRZpbmgaQj7HSl3ozX0cF_sb0=.90ad397f-075e-4387-921f-0c5d3ac9d939@github.com>

On Mon, 17 Nov 2025 20:19:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

This pull request has now been integrated.

Changeset: e534ee99
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e534ee99327fed2263302a00061fb46fcdc6e302
Stats:     1957 lines in 41 files changed: 914 ins; 823 del; 220 mod

8364343: Virtual Thread transition management needs to be independent of JVM TI

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: coleenp, dholmes, sspitsyn

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

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

From aph at openjdk.org  Wed Dec  3 20:40:45 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 3 Dec 2025 20:40:45 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read.

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

PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3608746121

From aph at openjdk.org  Wed Dec  3 20:45:53 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 3 Dec 2025 20:45:53 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <wOU0vkAx2Rnk5yOY9DcWnZpAGIJU8dvt0aAksOCKkRA=.6a8bf8a7-360d-4b27-82e6-5e19e4376b13@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

src/hotspot/share/oops/klass.cpp line 1063:

> 1061:   // This can be expensive, but it is worth checking that this klass is actually
> 1062:   // in the CLD graph but not in production.
> 1063: 

Suggestion:


Stray blank line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2586552890

From mr at openjdk.org  Wed Dec  3 20:47:40 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:40 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v12]
In-Reply-To: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
Message-ID: <2BNyWIHsF3Idzqy1u0MlC_K6nvb_k6_aWOKzHXhf1PQ=.326df265-59ff-4fe9-a244-dc88246a4afb@github.com>

On Wed, 3 Dec 2025 17:23:37 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small doc change

Changes requested by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536758143

From mr at openjdk.org  Wed Dec  3 20:47:48 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:48 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <1vNADqcyDvebfWHyjYF0BEgWb7-xhh_f2GHdBnEaZQQ=.9415cb27-f2b8-4214-86b2-72772d7cb278@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 37:

> 35:  * <p> The management interface is registered with the platform {@link MBeanServer
> 36:  * MBeanServer}. The {@link ObjectName ObjectName} that uniquely identifies the management
> 37:  * interface within the {@code MBeanServer} is: "jdk.management:type=HotSpotAOTCache".

Drop the colon after "is", and put the object name in `{@code ...}` rather than double quotes.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 44:

> 42:  * {@code HotSpotAOTCacheMXBean} defines one operation at this time to
> 43:  * end the AOT recording. More operations and/or properties may be added in a
> 44:  * future release.

Drop this paragraph. It's obvious that there's only one operation, and uncertain statements about future releases add no value.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 50:

> 48: public interface HotSpotAOTCacheMXBean extends PlatformManagedObject {
> 49:   /**
> 50:    * If an AOT recording is in progress, ends the recording. This operation completes

s/operation completes/method returns/

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 53:

> 51:    * after the AOT artifacts have been completely written.
> 52:    *
> 53:    * <p>The JVM will start recording AOT artifacts upon start-up if certain JVM options are

s/certain/appropriate/ -- "certain" suggests that you're not going to tell the reader what they are.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 57:

> 55:    * the {@code endRecording} method is called. Examples:
> 56:    *
> 57:    * <p> java -XX:AOTCacheOutput=app.aot ....

Put this command, and the others below, in `{@code ...}`, and precede them with a dollar prompt (`$`) so that they look more like command lines.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 63:

> 61:    *    that will be used to generate the AOT cache file app.aot. In a future execution of this application,
> 62:    *    -XX:AOTCache=app.aot can be provided to improve the application's
> 63:    *    start-up and warm-up performance.

Tighten and clarify: `The JVM records optimization information for the current application in the AOT cache file {@code app.aot}. in a future run of the application, the option {@code -XX:AOTCache=app.aot} will cause the JVM to use the cache to improve the application's startup and warmup performance.`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 69:

> 67:    *
> 68:    * <blockquote>
> 69:    *    The JVM will record optimization information about the current application

`The JVM records optimization information for the current application in the AOT configuration file {@code app.aotconfig}. ...`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 84:

> 82:    *
> 83:    * <p> There are also no APIs to querying whether the AOT recording is in progress, or what AOT
> 84:    * artifacts are being recorded.

Drop "Note:", it's meaningless. Merge these two paragraphs. s/to querying/to query/. s/the AOT/an AOT/.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 92:

> 90:    * procedures rely on an external agent to select the correct moment to end training.
> 91:    * In this way the selected length of training produces the correct set of AOT
> 92:    * optimizations in the AOT archive, without interfering with the application code.

You seem to be saying here that using this method from within an application is not necessarily the best approach, but you say it in a very roundabout way. Consider something like:

     * This method enables an application to end its own AOT recording
     * programatically, but that is not necessarily the best approach. Doing so
     * requires changing the application?s code, which might not be
     * feasible. Even when it is feasible, injecting training-specific logic
     * into the application reduces the similarity between training runs and
     * production runs, potentially making the AOT cache less effective. It may
     * be better to arrange for an external agent to end the training run,
     * thereby creating an AOT cache without interfering with the application?s
     * code.
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586483272
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586486393
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586493320
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586488596
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586490840
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586506998
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586509392
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586515533
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586550031

From mr at openjdk.org  Wed Dec  3 20:47:50 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:50 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
 <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
Message-ID: <C4YPT2GKTm42OjocWetcXwiTJ7xKDNppLKVNXxMkudg=.53fa3511-0cc2-442d-8f76-28328e0e5c8a@github.com>

On Wed, 3 Dec 2025 10:02:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed spaces and CRLF
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:
> 
>> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
>> 77:    * specification of the corresponding JVM command-line options, please refer
>> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.
> 
> One more late nit: these links have just the raw number in the link text. Better to have:
> 
> * to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

My original suggestion was to say `please refer to JEPs <a href=...>483</a> and <a href=...>514</a>`, but this is fine, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586511793

From macarte at openjdk.org  Wed Dec  3 22:29:24 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 22:29:24 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate feedback into documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6cd920da..8b0e27f2

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

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

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

From cjplummer at openjdk.org  Thu Dec  4 00:12:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 00:12:14 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v4]
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <dTo9l_r_euiVL63NM25gncIn8Axa6ixeWhGfR16BPeo=.38bfb037-efad-476d-ba4d-42ae8d05abfc@github.com>

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

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

  rename virtualThreadStartEventsPermanentlyEnabled to virtualThreadStartEventsEnabledForDeferredEventMode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28485/files
  - new: https://git.openjdk.org/jdk/pull/28485/files/e0a241a1..be9d1783

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

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

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

From cjplummer at openjdk.org  Thu Dec  4 00:19:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 00:19:25 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v5]
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <lKRzHfeykIRB-zMJa4_iRFDzX3IAx4reXe-s9nwieMI=.20711fbd-765a-4639-bd18-073c8a7b2fb0@github.com>

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed typo in comment
 - Add comment for virtualThreadStartEventsEnabledForDeferredEventMode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28485/files
  - new: https://git.openjdk.org/jdk/pull/28485/files/be9d1783..09ca7110

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

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

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

From sspitsyn at openjdk.org  Thu Dec  4 00:34:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Dec 2025 00:34:06 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
Message-ID: <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>

On Wed, 3 Dec 2025 07:22:51 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comments

We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module.
We got the following concerns:
 - Do we really need 3x implementations of the MacOS `tempdir` finder function?
 - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3609399390

From cjplummer at openjdk.org  Thu Dec  4 02:16:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 02:16:35 GMT
Subject: RFR: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
Message-ID: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>

When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.

I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more too this bug.

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

Commit messages:
 - handle ObjectCollectedException

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

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

From cjplummer at openjdk.org  Thu Dec  4 04:14:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 04:14:21 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with FATAL
 ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
Message-ID: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>

During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.

Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

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

Commit messages:
 - allow wrong phase during shutdown

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

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

From lmesnik at openjdk.org  Thu Dec  4 04:26:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 Dec 2025 04:26:00 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

Changes requested by lmesnik (Reviewer).

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 173:

> 171:         }
> 172:     }
> 173:     if (error == JVMTI_ERROR_WRONG_PHASE && gdata->vmDead && isVThread(thread)) {

Shouldn't be check for any daemon threads and not only virtual?

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

PR Review: https://git.openjdk.org/jdk/pull/28653#pullrequestreview-3537964272
PR Review Comment: https://git.openjdk.org/jdk/pull/28653#discussion_r2587444390

From dholmes at openjdk.org  Thu Dec  4 05:15:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 05:15:03 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

About a third of the way through. Mostly all pretty straight-forward but unclear why a number of _LP64 guards can be removed?

src/hotspot/share/cds/aotMetaspace.cpp line 1853:

> 1851: //
> 1852: // The range encompassing both spaces will be suitable to en/decode narrow Klass
> 1853: //  pointers: the base will be valid for encoding, the range [Base, End) and not

Suggestion:

//  pointers: the base will be valid for encoding the range [Base, End) and not

src/hotspot/share/cds/archiveBuilder.cpp line 671:

> 669:       dump_region->allocate(sizeof(address));
> 670:     }
> 671: #ifdef _LP64

Not obvious this isn't still needed.

src/hotspot/share/cds/archiveBuilder.cpp line 1140:

> 1138: };
> 1139: 
> 1140: #ifdef _LP64

Again not clear why this can be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3538084962
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587534751
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587540478
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587563999

From cjplummer at openjdk.org  Thu Dec  4 05:17:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 05:17:10 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
 <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>
Message-ID: <6kFy_mKp9sBhYXxFe8jiqTRNJNdYa9mvgucj5A56x4E=.50bf9cc8-f9d7-4d40-b556-4c5989b55a25@github.com>

On Thu, 4 Dec 2025 04:23:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
>> 
>> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 173:
> 
>> 171:         }
>> 172:     }
>> 173:     if (error == JVMTI_ERROR_WRONG_PHASE && gdata->vmDead && isVThread(thread)) {
> 
> Shouldn't be check for any daemon threads and not only virtual?

It's only possible to end up in this situation with vthreads. That's because when the debugger disconnects, we free all the ThreadNodes for vthreads. We don't do that for platform threads or non-java threads. threadControl_reset() is calling removeVThreads() when this issue turns up. There is no equivalent for other thread types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28653#discussion_r2587580289

From lmesnik at openjdk.org  Thu Dec  4 05:25:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 Dec 2025 05:25:54 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <iywEATo-86goybX2BlBLcsiEGBKvutU--KuatNkw8B0=.c209ba6c-6e2e-45f3-8bff-7fc49ee3c4a5@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

Thanks for explanation. 
Fix looks reasonable to me.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28653#pullrequestreview-3538175586

From stuefe at openjdk.org  Thu Dec  4 07:00:33 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:00:33 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v2]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <ldiIiY3LSNshPye3DZvJLoFzqF3drGAWabsO8siCeGU=.87f7cf4f-67c6-4cfa-9cd4-2a238a2272be@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/cds/aotMetaspace.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/64d7984a..141113a0

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

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

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

From stuefe at openjdk.org  Thu Dec  4 07:06:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:06:49 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestion from @theRealAph
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/141113a0..074a2337

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

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

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

From stuefe at openjdk.org  Thu Dec  4 07:06:52 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:06:52 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>
Message-ID: <crsYU_Tu05BFWgbBK3eFianA3GQ1zHl3Og9EgY7FRtI=.4976b9da-ef03-4f7e-b84c-12bbd8136b23@github.com>

On Thu, 4 Dec 2025 04:59:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestion from @theRealAph
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/cds/archiveBuilder.cpp line 671:
> 
>> 669:       dump_region->allocate(sizeof(address));
>> 670:     }
>> 671: #ifdef _LP64
> 
> Not obvious this isn't still needed.

That is a small simplification that should have been part of https://bugs.openjdk.org/browse/JDK-8363998. The test


alignment = nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift());


can be applied to 32-bit, too. There, precomputed_narrow_klass_shift() is zero.

> src/hotspot/share/cds/archiveBuilder.cpp line 1140:
> 
>> 1138: };
>> 1139: 
>> 1140: #ifdef _LP64
> 
> Again not clear why this can be removed.

Same reasoning. 32-bit now also uses narrow Klass pointers, so that code can be made unconditionally compilable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587823782
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587825926

From stuefe at openjdk.org  Thu Dec  4 07:09:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:09:01 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>
Message-ID: <tkxu-GE6GBi2tLDhE29Zv4k3_UuHnF4hpK83HPFzx1Y=.2f8639a0-5f0d-4286-9a2f-a4c911d7408d@github.com>

On Wed, 3 Dec 2025 20:37:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read.

Yes, "hide widespaces" is useful. Github is still surprisingly bad at managing large patches.

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

PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3610611623

From tschatzl at openjdk.org  Thu Dec  4 09:23:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 09:23:01 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <xLg53do1W6duJtvYnXeJaSBzCFNEHB0ldEhbLAJvqQI=.79dc4a70-eab9-495a-8c6f-993eff7ddc35@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28637#pullrequestreview-3538896024

From ayang at openjdk.org  Thu Dec  4 09:38:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 09:38:10 GMT
Subject: RFR: 8373086: Make isexceeded001.java more robust
Message-ID: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>

The original intended fix is to increase initial-heap-size so avoid gc, captured in [JDK-8373022](https://bugs.openjdk.org/browse/JDK-8373022). This is an alternative, which makes the test more resilient to changes in heaps/gcs.

Running `vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded002/TestDescription.java`
with `-XX:+UseParallelGC -Xcomp -XX:-TieredCompilation -XX:InitialRAMPercentage=0` fails about 10% of the time.

After applying the fix, `isexceeded002` passes 2,000 runs.

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

Commit messages:
 - test-bug-nsk

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

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

From jsikstro at openjdk.org  Thu Dec  4 09:57:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 09:57:00 GMT
Subject: RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
References: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
Message-ID: <a4Cgr-spOOsMfH9bYZYl1NUWPwQWhZ8DeBc73gZCR0M=.ffd78443-901f-485b-b12c-13b1d23777f7@github.com>

On Thu, 4 Dec 2025 09:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The original intended fix is to increase initial-heap-size so avoid gc, captured in [JDK-8373022](https://bugs.openjdk.org/browse/JDK-8373022). This is an alternative, which makes the test more resilient to changes in heaps/gcs.
> 
> Running `vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded002/TestDescription.java`
> with `-XX:+UseParallelGC -Xcomp -XX:-TieredCompilation -XX:InitialRAMPercentage=0` fails about 10% of the time.
> 
> After applying the fix, `isexceeded002` passes 2,000 runs.

Looks good. Interesting test bug.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28655#pullrequestreview-3539044879

From stuefe at openjdk.org  Thu Dec  4 11:05:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 11:05:59 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v2]
In-Reply-To: <36A5noLY70ktfD5Hjabo7xw3HDJmqi2rL3_OBrfNkTg=.c78dcf7e-faa6-47df-91e6-24b96769c499@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rm4JsWZQ9cCT8atMmnVuAdeyK18T6PAJFOUppCC5Vqw=.add3357a-d19a-4793-bd3a-e7f67d512bd7@github.com>
 <36A5noLY70ktfD5Hjabo7xw3HDJmqi2rL3_OBrfNkTg=.c78dcf7e-faa6-47df-91e6-24b96769c499@github.com>
Message-ID: <ZRvaVPGpvmPeEIIbuC7GY2ml-ch6VI5nq3LaoOmMOfE=.25840359-86ab-4cef-aef5-4e1f51d2d282@github.com>

On Wed, 29 Oct 2025 14:47:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
>> To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix 
> 
> I'm trying to understand what functionality you're after here. Is the specific number of open file descriptors important or is it enough to just report that there are "a lot" of file descriptors open? If so, @tstuefe's suggested approach of looking at `/proc/self/status` and FDSize and don't report the exact number if over some limit is a good compromise I think.
> 
> I couldn't find any good documentation for Mac's `proc_pidinfo`, but looking at the source code it's not an expensive operation at all (https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/bsd/kern/proc_info.c#L486). I know very little of AIX to have an opinion, but if it's an issue maybe we can skip reporting it for now?

> Thanks @jsikstro and @tstuefe for the insightful comments. Just to note, the maximum possible FDs (NOFILE) is already printed in VM.info (and maybe should be added to the hs_err file), the main idea of this patch is to provide the current number of open file descriptors for diagnosing FD exhaustion (compared against the max FD) and FD leaks.
> 
> Would a timed loop for both AIX and Linux (exiting the scan if it takes more than a set threshold) work 

that would be my preferred solution

> and what would be an acceptable threshold? 

A few ms; 50 maybe?

> Maybe we could report that the FD count above the current counted value if we reach the threshold or fall back to reporting the FDSize field from /proc/self/status on Linux as a rough estimate?

I would not put any work into this. Just report what you got, as in ">10000" or somesuch. If this time limit hits, we have a ton of file descriptors, or something is wrong with /proc; either is rare. The exact number does not matter then. An analyst would probably have to look at the machine or the VM process to check what's going on. E.g. who opens that many files.

> 
> Also, the Mac API is undocumented - https://zameermanji.com/blog/2021/8/1/counting-open-file-descriptors-on-macos/.

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

PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3611539814

From aph at openjdk.org  Thu Dec  4 12:02:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:02:30 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
Message-ID: <PEUWeI3-Cf6-D97C3UIwkF2tZu3uH6aSkl-1HU1frNM=.586665ea-8412-4871-9dcb-2a3163022d48@github.com>

On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion from @theRealAph
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1281:

> 1279:   Rtmp1 = op->tmp3()->as_register();
> 1280:   select_different_registers(obj, dst, k_RInfo, klass_RInfo, Rtmp1);
> 1281: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588781883

From aph at openjdk.org  Thu Dec  4 12:06:05 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:06:05 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
Message-ID: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>

On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion from @theRealAph
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:

> 53:   static bool can_use() { return can_map() || can_load(); }
> 54: 
> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}

Suggestion:

  // Can this VM map archived heap region? Currently only G1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588797500

From stuefe at openjdk.org  Thu Dec  4 13:36:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 13:36:43 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/074a2337..9e85a653

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

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

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

From tschatzl at openjdk.org  Thu Dec  4 13:41:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 13:41:38 GMT
Subject: RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
References: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
Message-ID: <65ey4pscSDdu6KloQVdK3BtejZ7e44huD0_ZgQfIqR8=.a1e9bb8f-f178-4d30-98ff-40a827336843@github.com>

On Thu, 4 Dec 2025 09:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The original intended fix is to increase initial-heap-size so avoid gc, captured in [JDK-8373022](https://bugs.openjdk.org/browse/JDK-8373022). This is an alternative, which makes the test more resilient to changes in heaps/gcs.
> 
> Running `vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded002/TestDescription.java`
> with `-XX:+UseParallelGC -Xcomp -XX:-TieredCompilation -XX:InitialRAMPercentage=0` fails about 10% of the time.
> 
> After applying the fix, `isexceeded002` passes 2,000 runs.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28655#pullrequestreview-3540090548

From stuefe at openjdk.org  Thu Dec  4 14:06:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 14:06:20 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
Message-ID: <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>

On Thu, 4 Dec 2025 12:03:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestion from @theRealAph
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:
> 
>> 53:   static bool can_use() { return can_map() || can_load(); }
>> 54: 
>> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}
> 
> Suggestion:
> 
>   // Can this VM map archived heap region? Currently only G1.

After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...

That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.

I'll take a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589215456

From aph at openjdk.org  Thu Dec  4 14:43:06 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 14:43:06 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
 <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
Message-ID: <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>

On Thu, 4 Dec 2025 14:03:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:
>> 
>>> 53:   static bool can_use() { return can_map() || can_load(); }
>>> 54: 
>>> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}
>> 
>> Suggestion:
>> 
>>   // Can this VM map archived heap region? Currently only G1.
>
> After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...
> 
> That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.
> 
> I'll take a look.

Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates

Rule 1: Comments should not duplicate the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589349492

From stuefe at openjdk.org  Thu Dec  4 15:04:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 15:04:51 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
 <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
 <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>
Message-ID: <6t_cgEV2UcFEf5C148g7aIj9AObCmwJI_YMfJ_s7VUs=.6681d5cc-4c69-46dd-9d17-89a2d2d723ea@github.com>

On Thu, 4 Dec 2025 14:39:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...
>> 
>> That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.
>> 
>> I'll take a look.
>
> Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates
> 
> Rule 1: Comments should not duplicate the code

Ashu just reminded me that we do relocate uncompressed oops when loading the CDS archive at runtime. We never got around to do that for uncompressed Klass pointers in object headers, and it was also never really necessary.

So you are right, the comment should either just be removed or explain the G1 restriction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589430925

From cjplummer at openjdk.org  Thu Dec  4 16:10:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 16:10:54 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java line 32:

> 30:  * @run build TestScaffold VMConnection TargetListener TargetAdapter
> 31:  * @run compile -g MethodInvokeWithTraceOnTest.java
> 32:  * @run driver MethodInvokeWithTraceOnTest -XX:InitialHeapSize=100M

Are you seeing failures due to an ObjectCollectionException? If so, avoiding GC is not the proper way to fix it. Even with a larger initial heap, there can still be an object collected with ZGC. We shouldn't have any debugger tests that rely on a GC not happening in the debugee. The proper fix is usually calling ObjectReference.disableCollection(), although sometimes even that is not enough (the call can happen too late if the debugee is not suspended).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2589682868

From jsikstro at openjdk.org  Thu Dec  4 16:17:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 16:17:02 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <-2gVJG09G3ER3zGMBJA7kbRsEOFzGMc32Qy7Hstw9lY=.8a29fb54-6083-4ee5-8248-f776b29d3102@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <-2gVJG09G3ER3zGMBJA7kbRsEOFzGMc32Qy7Hstw9lY=.8a29fb54-6083-4ee5-8248-f776b29d3102@github.com>
Message-ID: <8W4ZDhEggsyeHNgX3djdmJudjNZAqjTcBw0s0t0K1_g=.48dce781-5025-4c98-933a-207264831073@github.com>

On Wed, 3 Dec 2025 16:42:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It's probably just the timing of the GC that determines whether the initial small heap is a problem or not. If you want the SA tests to be reliable with something like InitialRAMPercentage=0, probably all of the tests should be updated. However, personally I don't think this type of fix should be necessary unless you feel testing in the manner is something we want to support. There are plenty of tests that start failing when non-standard command line options are used.

FYI we just integrated a change that sets InitialRAMPercentage=0 for JDK 26 that we've been working on (see https://github.com/openjdk/jdk/pull/28641). We've run up to Oracle's tier8 twice now, and apart from the tests that are included in this PR, we've not seen any other SA failures.


Of course there might be other intermittent failures in the future, in which case I see two approaches moving forward: problem listing or bumping the initial heap size for the affected tests, or going over all SA tests and making sure that they all run with a "large" initial heap size (like 100MB). Unless we start seing many (for some definition of many) test failures from now, a pragmatic compromise is to selectively bump the initial heap size of such tests, like I do in this PR.

Of course, the optimal approach would be to make any affected SA tests more robst to GC timings. But, since I'm not sure how much time we want to invest in improving SA tests, bumping the heap size is likely a good compromise here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3613022715

From jsikstro at openjdk.org  Thu Dec  4 16:20:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 16:20:00 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>
Message-ID: <KzTxRy5xswylI_Nipeq2R9xJ6zOEoRyCCMlG0nhfMv0=.4d989cca-1634-42d2-a08c-357f56c52210@github.com>

On Thu, 4 Dec 2025 16:07:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hello,
>> 
>>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>>  
>> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
>> 
>> Testing:
>> * Rerun 10 times with Serial and Parallel for each test and they all pass
>
> test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java line 32:
> 
>> 30:  * @run build TestScaffold VMConnection TargetListener TargetAdapter
>> 31:  * @run compile -g MethodInvokeWithTraceOnTest.java
>> 32:  * @run driver MethodInvokeWithTraceOnTest -XX:InitialHeapSize=100M
> 
> Are you seeing failures due to an ObjectCollectionException? If so, avoiding GC is not the proper way to fix it. Even with a larger initial heap, there can still be an object collected with ZGC. We shouldn't have any debugger tests that rely on a GC not happening in the debugee. The proper fix is usually calling ObjectReference.disableCollection(), although sometimes even that is not enough (the call can happen too late if the debugee is not suspended).

Yes, we're seeing a failure due to ObjectCollectionException. This is because the heap size is now much smaller, causing more frequent GCs. "Reverting" to a larger initial heap size is a straightforward fix so that we can continue running this test.

I think a more "robust" approach is better, which we could do in a follow-up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2589716575

From cjplummer at openjdk.org  Thu Dec  4 16:57:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 16:57:25 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <KzTxRy5xswylI_Nipeq2R9xJ6zOEoRyCCMlG0nhfMv0=.4d989cca-1634-42d2-a08c-357f56c52210@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>
 <KzTxRy5xswylI_Nipeq2R9xJ6zOEoRyCCMlG0nhfMv0=.4d989cca-1634-42d2-a08c-357f56c52210@github.com>
Message-ID: <YjuA_JJR7nGicDxPR8fcOH-ss7pSm6MZI0_v1is17OE=.16bf7653-9844-4b39-8084-8ac0d46b8073@github.com>

On Thu, 4 Dec 2025 16:17:27 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java line 32:
>> 
>>> 30:  * @run build TestScaffold VMConnection TargetListener TargetAdapter
>>> 31:  * @run compile -g MethodInvokeWithTraceOnTest.java
>>> 32:  * @run driver MethodInvokeWithTraceOnTest -XX:InitialHeapSize=100M
>> 
>> Are you seeing failures due to an ObjectCollectionException? If so, avoiding GC is not the proper way to fix it. Even with a larger initial heap, there can still be an object collected with ZGC. We shouldn't have any debugger tests that rely on a GC not happening in the debugee. The proper fix is usually calling ObjectReference.disableCollection(), although sometimes even that is not enough (the call can happen too late if the debugee is not suspended).
>
> Yes, we're seeing a failure due to ObjectCollectionException. This is because the heap size is now much smaller, causing more frequent GCs. "Reverting" to a larger initial heap size is a straightforward fix so that we can continue running this test.
> 
> I think a more "robust" approach is better, which we could do in a follow-up.

Can you tell me how to run this test with a small GC that reproduces the ObjectCollectionException?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2589852760

From jsikstro at openjdk.org  Thu Dec  4 17:12:22 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 17:12:22 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <YjuA_JJR7nGicDxPR8fcOH-ss7pSm6MZI0_v1is17OE=.16bf7653-9844-4b39-8084-8ac0d46b8073@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>
 <KzTxRy5xswylI_Nipeq2R9xJ6zOEoRyCCMlG0nhfMv0=.4d989cca-1634-42d2-a08c-357f56c52210@github.com>
 <YjuA_JJR7nGicDxPR8fcOH-ss7pSm6MZI0_v1is17OE=.16bf7653-9844-4b39-8084-8ac0d46b8073@github.com>
Message-ID: <zWHHEo7tAsJu6YRErjj-HYxoMyj5CM1FwY8Fkx0uwvw=.ffde362f-b2f0-4964-b1cc-8128a02e293a@github.com>

On Thu, 4 Dec 2025 16:54:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, we're seeing a failure due to ObjectCollectionException. This is because the heap size is now much smaller, causing more frequent GCs. "Reverting" to a larger initial heap size is a straightforward fix so that we can continue running this test.
>> 
>> I think a more "robust" approach is better, which we could do in a follow-up.
>
> Can you tell me how to run this test with a small GC that reproduces the ObjectCollectionException?

We've only seen this on windows-x64-debug so far, it should fail on mainline right now, given it is removed from the ProblemList it's in. I haven't updated this PR to remove the ProblemList just yet, but will do.

If you want to be explicit you can run it with `-XX:InitialRAMPercentage=0`, but this is the new default in mainline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2589900851

From cjplummer at openjdk.org  Thu Dec  4 17:15:43 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 17:15:43 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <iZ2T20L23hOaeyfV0Ya1Xq1obnOktWOzvZ5QpX-50qk=.9c4efa2c-4062-4a73-9e44-7def9d94a3f1@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

> > It's probably just the timing of the GC that determines whether the initial small heap is a problem or not. If you want the SA tests to be reliable with something like InitialRAMPercentage=0, probably all of the tests should be updated. However, personally I don't think this type of fix should be necessary unless you feel testing in the manner is something we want to support. There are plenty of tests that start failing when non-standard command line options are used.
> 
> FYI we just integrated a change that sets InitialRAMPercentage=0 for JDK 26 that we've been working on (see #28641). We've run up to Oracle's tier8 twice now, and apart from the tests that are included in this PR, we've not seen any other SA failures.
> 
> Of course there might be other intermittent failures in the future, in which case I see two approaches moving forward: problem listing or bumping the initial heap size for the affected tests, or going over all SA tests and making sure that they all run with a "large" initial heap size (like 100MB). Unless we start seing many (for some definition of many) test failures from now, a pragmatic compromise is to selectively bump the initial heap size of such tests, like I do in this PR.
> 
> Of course, the optimal approach would be to make any affected SA tests more robst to GC timings. But, since I'm not sure how much time we want to invest in improving SA tests, bumping the heap size is likely a good compromise here.

For the most part the SA tests are fine if there is a GC. The way they usually work is to launch the debuggee, wait for it to reach a stable point (all threads idle), and then start to query the debuggee. If a GC happens before reaching stability, that should be fine, and after stability we wouldn't expect any GCs no matter what the heap size is. There are some SA tests that run on active processes where GCs can happen, but they are written to allow for errors.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3613332793

From dholmes at openjdk.org  Thu Dec  4 20:49:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 20:49:30 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v4]
In-Reply-To: <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <9xA0sgLimhZXv2g6kOQTRtzjcVZi7lvv6niEV9AxuUM=.dfcfe62c-8d0f-4825-8115-4dbac4bee5b0@github.com>
Message-ID: <4hDJOToVSyoWzZFmsoLycsmkF6HVqe7LRFan_VyDdgo=.2e958a45-4355-45f4-8b10-053f7338ee92@github.com>

On Mon, 1 Dec 2025 23:38:20 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

> This PR works fine on both Linux AMD64 and Linux AArch64. All of hotspot/jtreg/serviceability/sa tests have been passed on both platforms.

@YaSuenag it doesn't seem to work on macOS however. We get an exception moving from the native frames to Java frames:


"Reference Handler" #15 daemon prio=10 tid=0x00000009f3091e10 nid=29955 waiting on condition [0x000000017059e000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00000001890b64f8		????????
0x00000001083f8810	__ZN15PlatformMonitor4waitEy + 0x94
0x000000010836f60c	__ZN7Monitor4waitEy + 0x154
0x0000000107fa19dc	_JVM_WaitForReferencePendingList + 0x108
0x00000001192b5a48	sun.jvm.hotspot.utilities.UnsupportedPlatformException
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.cdbg.CFrame.toFrame(CFrame.java:78)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:248)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)

Bug is being filed

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3614262403

From cjplummer at openjdk.org  Thu Dec  4 21:06:15 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 21:06:15 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can fail
 with ObjectCollectedException when run with a small heap
Message-ID: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>

With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.

Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

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

Commit messages:
 - fix minor typo in comment
 - fix minor typo in comment
 - handle ObjectCollectedException

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

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

From cjplummer at openjdk.org  Thu Dec  4 21:35:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 21:35:07 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <kJi2W9o0Pib1mBae3p3YJvqjKS-HtW7bhNqE--Qh0Rs=.734128e8-c9c9-46c8-97dd-2d68bbea86de@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java line 66:

> 64:             // Setting the initial heap size to a reasonably high number avoids
> 65:             // running a GC.
> 66:             theApp = LingeredApp.startApp(gc, "-XX:InitialHeapSize=100M");

This test does tries to scan a section of the java heap. When a GC happens, this section becomes empty, so the expected output is not present. Your fix seems reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2590648795

From cjplummer at openjdk.org  Thu Dec  4 21:35:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 21:35:09 GMT
Subject: RFR: 8373022: Increase initial heap size for test which assumes no
 GC
In-Reply-To: <zWHHEo7tAsJu6YRErjj-HYxoMyj5CM1FwY8Fkx0uwvw=.ffde362f-b2f0-4964-b1cc-8128a02e293a@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <8SvQs6F6EwChXs0nGPFeB_mL7-czEiavHOx27lYshXQ=.4e1b16f8-6455-4a64-8321-ea3a2b981bb8@github.com>
 <KzTxRy5xswylI_Nipeq2R9xJ6zOEoRyCCMlG0nhfMv0=.4d989cca-1634-42d2-a08c-357f56c52210@github.com>
 <YjuA_JJR7nGicDxPR8fcOH-ss7pSm6MZI0_v1is17OE=.16bf7653-9844-4b39-8084-8ac0d46b8073@github.com>
 <zWHHEo7tAsJu6YRErjj-HYxoMyj5CM1FwY8Fkx0uwvw=.ffde362f-b2f0-4964-b1cc-8128a02e293a@github.com>
Message-ID: <SPma5jZ9-o41JwU5TT62wdN9klsUMuS1pqPzZMCISRw=.d8a2003a-50c4-41a7-af47-2a65d0d487d1@github.com>

On Thu, 4 Dec 2025 17:09:46 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Can you tell me how to run this test with a small GC that reproduces the ObjectCollectionException?
>
> We've only seen this on windows-x64-debug so far, it should fail on mainline right now, given it is removed from the ProblemList it's in. I haven't updated this PR to remove the ProblemList just yet, but will do.
> 
> If you want to be explicit you can run it with `-XX:InitialRAMPercentage=0`, but this is the new default in mainline.

This is a JDI bug, not a test bug. I'll fix this with #28666.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2590643913

From sspitsyn at openjdk.org  Thu Dec  4 22:03:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Dec 2025 22:03:31 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <-WiLCh7CwZsXgwqK1xMliAafRrrreC1wiVLMe40OCZk=.3b1001bf-4c5c-407f-8d67-7fc6088f2288@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28653#pullrequestreview-3542266577

From sspitsyn at openjdk.org  Thu Dec  4 22:03:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Dec 2025 22:03:34 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <6kFy_mKp9sBhYXxFe8jiqTRNJNdYa9mvgucj5A56x4E=.50bf9cc8-f9d7-4d40-b556-4c5989b55a25@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
 <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>
 <6kFy_mKp9sBhYXxFe8jiqTRNJNdYa9mvgucj5A56x4E=.50bf9cc8-f9d7-4d40-b556-4c5989b55a25@github.com>
Message-ID: <WuSHJriIp5_KIbadU2DCqM0M4gpxbA28W03sP590zlg=.85bd7c91-8106-49fd-9553-c587ad44a6bc@github.com>

On Thu, 4 Dec 2025 05:14:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 173:
>> 
>>> 171:         }
>>> 172:     }
>>> 173:     if (error == JVMTI_ERROR_WRONG_PHASE && gdata->vmDead && isVThread(thread)) {
>> 
>> Shouldn't be check for any daemon threads and not only virtual?
>
> It's only possible to end up in this situation with vthreads. That's because when the debugger disconnects, we free all the ThreadNodes for vthreads. We don't do that for platform threads or non-java threads. threadControl_reset() is calling removeVThreads() when this issue turns up. There is no equivalent for other thread types.

Should `JVMTI_ERROR_THREAD_NOT_ALIVE` be added to this check for better reliability?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28653#discussion_r2590723369

From sspitsyn at openjdk.org  Thu Dec  4 22:10:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Dec 2025 22:10:24 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <Cwdl4DeWCLu0Tpebamjn_kLR-2k1YG2DPfwUgB3Nj74=.a773bfb7-d87f-4a10-887b-4e455c0785d8@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28666#pullrequestreview-3542310799

From amenkov at openjdk.org  Thu Dec  4 22:14:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 4 Dec 2025 22:14:52 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <E3NLZyWdqyoBfCdGyc91PMWXQvX9BqeS2S94wGWYdhI=.b66bf853-d762-455e-a63d-5e12a0807ec4@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28653#pullrequestreview-3542322873

From amenkov at openjdk.org  Thu Dec  4 22:22:44 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 4 Dec 2025 22:22:44 GMT
Subject: RFR: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
In-Reply-To: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
References: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
Message-ID: <M5tGLYX_rvGLxjpEPUV9sHG-7C9Huib2LFq2vLCY-DA=.46856d71-7a24-4907-aa6c-db297ae8c24a@github.com>

On Thu, 4 Dec 2025 02:07:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.
> 
> I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more too this bug.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28652#pullrequestreview-3542349135

From coleenp at openjdk.org  Thu Dec  4 22:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 22:43:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
Message-ID: <EzHVGdHIdqSRsFlzhFFOHeYYVsNWXu6lXWJYhJAPV_I=.b905813d-a2ef-4b73-87dc-9317509be561@github.com>

On Wed, 3 Dec 2025 13:17:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take out ?: for array classes in set_raw_access_flags call.

Thanks for reviewing and your help, Vladimir, Dean, Chen and Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/28371#issuecomment-3614608117

From coleenp at openjdk.org  Thu Dec  4 22:43:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 22:43:52 GMT
Subject: Integrated: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <QhjAOtWuWDyJkO-C7PE4GVPIDZrxDfeRRxYgp8D2-zs=.df6180bc-0860-432b-a048-109c8bb2afc3@github.com>

On Tue, 18 Nov 2025 13:27:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

This pull request has now been integrated.

Changeset: 13e32bf1
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13e32bf1667a3be8492d1e4e3a273951202acd9c
Stats:     166 lines in 25 files changed: 75 ins; 59 del; 32 mod

8372098: Move AccessFlags to InstanceKlass

Reviewed-by: liach, vlivanov, dlong, sspitsyn

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

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

From amenkov at openjdk.org  Thu Dec  4 23:07:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 4 Dec 2025 23:07:02 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v5]
In-Reply-To: <lKRzHfeykIRB-zMJa4_iRFDzX3IAx4reXe-s9nwieMI=.20711fbd-765a-4639-bd18-073c8a7b2fb0@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <lKRzHfeykIRB-zMJa4_iRFDzX3IAx4reXe-s9nwieMI=.20711fbd-765a-4639-bd18-073c8a7b2fb0@github.com>
Message-ID: <QpUgyf3fBV-CSBPho0bRU8oewuFp99nzfY-pcnRNaAw=.d3df1621-3913-40bc-8879-74b20bb4d131@github.com>

On Thu, 4 Dec 2025 00:19:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
>> 
>> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
>> 
>> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed typo in comment
>  - Add comment for virtualThreadStartEventsEnabledForDeferredEventMode

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28485#pullrequestreview-3542494682

From amenkov at openjdk.org  Thu Dec  4 23:45:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 4 Dec 2025 23:45:55 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <9SaM5oyokFfL1cr2aVDOpmS0sVqQGfTrIhCKJ6nigps=.b0f1d1a1-f5ac-4d8e-9771-2500a6843238@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

I think better solution would be to catch `ObjectCollectedException` in `EventSetImpl.toString` implementations (and print al least event name).
But it might not be worth the effort, so it's up to you

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28666#pullrequestreview-3542567864

From cjplummer at openjdk.org  Thu Dec  4 23:58:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 23:58:58 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <9SaM5oyokFfL1cr2aVDOpmS0sVqQGfTrIhCKJ6nigps=.b0f1d1a1-f5ac-4d8e-9771-2500a6843238@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
 <9SaM5oyokFfL1cr2aVDOpmS0sVqQGfTrIhCKJ6nigps=.b0f1d1a1-f5ac-4d8e-9771-2500a6843238@github.com>
Message-ID: <tXXYQiWZ9o2NMzHU2jAhjAmV4IHEYhZU-b1ZAFVWBVY=.97f2bf81-8821-4d50-bcf5-0e9fc15693b0@github.com>

On Thu, 4 Dec 2025 23:42:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I think better solution would be to catch `ObjectCollectedException` in `EventSetImpl.toString` implementations (and print al least event name).
> But it might not be worth the effort, so it's up to you

I think your suggesting to implement it in all of the Event subclasses implemented as inner classes of EventSetImpl, right?

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3614776321

From cjplummer at openjdk.org  Fri Dec  5 00:02:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 00:02:57 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <tXXYQiWZ9o2NMzHU2jAhjAmV4IHEYhZU-b1ZAFVWBVY=.97f2bf81-8821-4d50-bcf5-0e9fc15693b0@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
 <9SaM5oyokFfL1cr2aVDOpmS0sVqQGfTrIhCKJ6nigps=.b0f1d1a1-f5ac-4d8e-9771-2500a6843238@github.com>
 <tXXYQiWZ9o2NMzHU2jAhjAmV4IHEYhZU-b1ZAFVWBVY=.97f2bf81-8821-4d50-bcf5-0e9fc15693b0@github.com>
Message-ID: <XMh33DlkaJki-foZnM0XgXPiWhCzW4C_pBf0uY7pnTs=.78f62d10-aec8-4cf8-bdf7-60865885fe60@github.com>

On Thu, 4 Dec 2025 23:56:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think your suggesting to implement it in all of the Event subclasses implemented as inner classes of EventSetImpl, right?

ThreadedEventImpl has the following for toString():

            return eventName() + " in thread " + thread.name();

This is the one being triggerd by the test via the thread.name() call. LocatableEventImpl inherits from ThreadedEventImpl and has its own toString() with the same thread.name() reference, so it also needs to be fixed. I think that might be it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3614783445

From cjplummer at openjdk.org  Thu Dec  4 22:25:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Dec 2025 22:25:37 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <WuSHJriIp5_KIbadU2DCqM0M4gpxbA28W03sP590zlg=.85bd7c91-8106-49fd-9553-c587ad44a6bc@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
 <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>
 <6kFy_mKp9sBhYXxFe8jiqTRNJNdYa9mvgucj5A56x4E=.50bf9cc8-f9d7-4d40-b556-4c5989b55a25@github.com>
 <WuSHJriIp5_KIbadU2DCqM0M4gpxbA28W03sP590zlg=.85bd7c91-8106-49fd-9553-c587ad44a6bc@github.com>
Message-ID: <6cAHQMZ3XCeKi-Qvba0XU8cCCJqLxenqPDubqpLZ4zg=.5560f8ae-ae67-4fb5-b14f-3b5735fb8043@github.com>

On Thu, 4 Dec 2025 21:58:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It's only possible to end up in this situation with vthreads. That's because when the debugger disconnects, we free all the ThreadNodes for vthreads. We don't do that for platform threads or non-java threads. threadControl_reset() is calling removeVThreads() when this issue turns up. There is no equivalent for other thread types.
>
> Should `JVMTI_ERROR_THREAD_NOT_ALIVE` be added to this check for better reliability?

JVMTI_ERROR_THREAD_NOT_ALIVE is already checked at line 161.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28653#discussion_r2590783597

From amenkov at openjdk.org  Fri Dec  5 00:22:00 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 5 Dec 2025 00:22:00 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <S3MEdwbiBPgRlpsXYhkFPDTBZg705B6nzB688nOPqzE=.3ac354a6-80a8-479f-9d71-933eab1da895@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

> > I think better solution would be to catch `ObjectCollectedException` in `EventSetImpl.toString` implementations (and print al least event name).
> > But it might not be worth the effort, so it's up to you
> 
> I think your suggesting to implement it in all of the Event subclasses implemented as inner classes of EventSetImpl, right?

It would be more complete solution, but even fixing only `EventSetImpl.toString` (for each event, printing event name (or class name of the event) + "<got ObjectCollectedException>" on the exception ) should be good enough

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3614827467

From sspitsyn at openjdk.org  Fri Dec  5 00:22:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 00:22:57 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <6cAHQMZ3XCeKi-Qvba0XU8cCCJqLxenqPDubqpLZ4zg=.5560f8ae-ae67-4fb5-b14f-3b5735fb8043@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
 <7aIFDXzYAmdr3K-QGw4cl_ZKGdcKyTyrnToQkZX-ED0=.7bfb0160-df4e-4d62-9e9a-f7dd6c727bb2@github.com>
 <6kFy_mKp9sBhYXxFe8jiqTRNJNdYa9mvgucj5A56x4E=.50bf9cc8-f9d7-4d40-b556-4c5989b55a25@github.com>
 <WuSHJriIp5_KIbadU2DCqM0M4gpxbA28W03sP590zlg=.85bd7c91-8106-49fd-9553-c587ad44a6bc@github.com>
 <6cAHQMZ3XCeKi-Qvba0XU8cCCJqLxenqPDubqpLZ4zg=.5560f8ae-ae67-4fb5-b14f-3b5735fb8043@github.com>
Message-ID: <hYxEzIzRZZH_nRtoEcBonGpI8udtZ0y0r82fxr9aMiY=.22e6bbe7-520f-4b83-ab6f-f812f2adfb4c@github.com>

On Thu, 4 Dec 2025 22:22:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Should `JVMTI_ERROR_THREAD_NOT_ALIVE` be added to this check for better reliability?
>
> JVMTI_ERROR_THREAD_NOT_ALIVE is already checked at line 161.

agreed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28653#discussion_r2591012348

From cjplummer at openjdk.org  Fri Dec  5 00:29:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 00:29:55 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <FF6VxaQndaxDXzEzuEoxqF5N7pJTKQNGOAb3L_QUj3g=.0ac5acae-1762-4acb-b2b8-369866948162@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

> It would be more complete solution, but even fixing only `EventSetImpl.toString` (for each event, printing event name (or class name of the event) + "" on the exception ) should be good enough

I don't think EventSetImpl.toString() is involved at all, although if called it can suffer the same ObjectCollectedException, which would be fixed if the issue is addressed in the toString() method of the Event sub-classes instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3614843314

From sspitsyn at openjdk.org  Fri Dec  5 00:33:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 00:33:59 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v5]
In-Reply-To: <lKRzHfeykIRB-zMJa4_iRFDzX3IAx4reXe-s9nwieMI=.20711fbd-765a-4639-bd18-073c8a7b2fb0@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <lKRzHfeykIRB-zMJa4_iRFDzX3IAx4reXe-s9nwieMI=.20711fbd-765a-4639-bd18-073c8a7b2fb0@github.com>
Message-ID: <fpgGZhR48cVQvge7v6wt5N97stDPfCOxmCpCDoh-AwA=.82e126eb-48da-45db-9681-27b58f71ab79@github.com>

On Thu, 4 Dec 2025 00:19:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
>> 
>> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
>> 
>> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed typo in comment
>  - Add comment for virtualThreadStartEventsEnabledForDeferredEventMode

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28485#pullrequestreview-3542659993

From cjplummer at openjdk.org  Fri Dec  5 01:14:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 01:14:37 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap [v2]
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <ci9Fl6dVXTz4egGcnK_4sm0b129UUufvCtpkMUA-yPM=.232e771f-93b9-406c-bfe7-eb2ec494c921@github.com>

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

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

  better implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28666/files
  - new: https://git.openjdk.org/jdk/pull/28666/files/c46c099f..6e7ba1be

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

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

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

From cjplummer at openjdk.org  Fri Dec  5 01:16:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 01:16:54 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <CnL6Wz6KqcSd8_D4-LXneu9tCDehFmF6oR5Vkbe_I9c=.93dc3acc-b330-4a96-b002-cd044e6faba4@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

I've updated the implementation so now the event type is printed even if there is an ObjectCollectedException. Turns out I was worng about this being triggered by a VirtualThreadEndEvent. It was actually a ClassPrepareEvent, but it was for the class VirtualThreadEndEvent. Here's all the output for the event set, including the handling of the ObjectCollectedException (2nd to last line).

```[JDI: Receiving Command(id=188) JDWP.Event.Composite]
[JDI: Receiving:                suspendPolicy(byte): 0]
[JDI: Receiving:                events(Events[]): ]
[JDI: Receiving:                    events[i](Events): ]
[JDI: Receiving:                    eventKind(byte): 8]
[JDI: Receiving:                        requestID(int): 2]
[JDI: Receiving:                        thread(ThreadReferenceImpl): ref=151]
[JDI: Receiving:                        refTypeTag(byte): 1]
[JDI: Receiving:                        typeID(long): ref=231]
[JDI: Receiving:                        signature(String): Ljdk/internal/event/VirtualThreadEndEvent;]
[JDI: Receiving:                        status(int): 3]
[JDI: EventSet: SUSPEND_NONE]
[JDI: Looking up Class, signature='Ljdk/internal/event/VirtualThreadEndEvent;', id=231]
[JDI: Caching new ReferenceType, sig=Ljdk/internal/event/VirtualThreadEndEvent;, id=231]
[JDI: Sending Command(id=438) JDWP.ThreadReference.Name]
[JDI: Sending:                 thread(ThreadReferenceImpl): ref=151]
[JDI: Event: ClassPrepareEvent in thread <thread collected>]
[JDI: Handled Prepare Event for jdk.internal.event.VirtualThreadEndEvent]```

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3614923760

From amenkov at openjdk.org  Fri Dec  5 01:31:01 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 5 Dec 2025 01:31:01 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap [v2]
In-Reply-To: <ci9Fl6dVXTz4egGcnK_4sm0b129UUufvCtpkMUA-yPM=.232e771f-93b9-406c-bfe7-eb2ec494c921@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
 <ci9Fl6dVXTz4egGcnK_4sm0b129UUufvCtpkMUA-yPM=.232e771f-93b9-406c-bfe7-eb2ec494c921@github.com>
Message-ID: <2WG7TI4zYgguPEvI9YVICtf_SAsp2DaY0qe5Boa6itk=.fde5195c-3674-47c1-96cd-b27ad1c85a66@github.com>

On Fri, 5 Dec 2025 01:14:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
>> 
>> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better implementation

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28666#pullrequestreview-3542748713

From sspitsyn at openjdk.org  Fri Dec  5 01:38:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 01:38:47 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v8]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <Y2_Ok1BMRugWOI_8jl2UNGgz4SWetNMjNC7SPuyDf58=.85d6112f-bcab-4da5-8246-e7b6df52d155@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - merge: fix merge error
 - Merge
 - Merge
 - review: optimize hide_single_stepping and post_method_exit
 - review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS
 - review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx)
 - review: fix typo in a EATests.java comment
 - cleanup: removed an old code fragment in frame.cpp
 - 6960970: Debugger very slow during stepping

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

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=07
  Stats: 255 lines in 22 files changed: 158 ins; 61 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

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

From sspitsyn at openjdk.org  Fri Dec  5 02:33:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 02:33:34 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v9]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <jqqycDJFS3q3T3Ceifau6VHhiInSnHy2ML7nJKRHKww=.fda3bdc9-1b40-4347-9cc0-f73135031f00@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

  merge: add fragments dropped by incorrect merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/9d2589be..91df8454

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

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

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

From lmesnik at openjdk.org  Fri Dec  5 06:40:23 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Dec 2025 06:40:23 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual thread
 factory testing
Message-ID: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>

Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.

The ThreadInfo is not returned for virtual threads and some bean functions return -1.

Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

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

Commit messages:
 - 8373127: Update nsk/monitoring tests to support virtual thread factory testing

Changes: https://git.openjdk.org/jdk/pull/28673/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373127
  Stats: 75 lines in 7 files changed: 47 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/28673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28673/head:pull/28673

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

From kevinw at openjdk.org  Fri Dec  5 09:15:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 5 Dec 2025 09:15:57 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
In-Reply-To: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
Message-ID: <Mg_Y_-MmMKX4aNaIrRTFUcN43ZKrUlScY_UribKTBbc=.cc76d36c-0cb3-495e-bc0a-e555a0e04566@github.com>

On Fri, 5 Dec 2025 06:34:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
> 
> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
> 
> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/BaseBehaviorTest.java line 78:

> 76:         if (Thread.currentThread().isVirtual()) {
> 77:             if (result != -1)
> 78:                 throw new TestFailure("Failure! ggetThreadAllocatedBytes(id) should "

gget typo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28673#discussion_r2591948101

From alanb at openjdk.org  Fri Dec  5 09:22:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Dec 2025 09:22:01 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
In-Reply-To: <Mg_Y_-MmMKX4aNaIrRTFUcN43ZKrUlScY_UribKTBbc=.cc76d36c-0cb3-495e-bc0a-e555a0e04566@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
 <Mg_Y_-MmMKX4aNaIrRTFUcN43ZKrUlScY_UribKTBbc=.cc76d36c-0cb3-495e-bc0a-e555a0e04566@github.com>
Message-ID: <tJWXskOzMBcqSHymzaVOH-iC5uaSiJOM2AqXKv24MoI=.b6751719-c175-4349-9512-493fbf88bc61@github.com>

On Fri, 5 Dec 2025 09:12:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
>> 
>> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
>> 
>> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/BaseBehaviorTest.java line 78:
> 
>> 76:         if (Thread.currentThread().isVirtual()) {
>> 77:             if (result != -1)
>> 78:                 throw new TestFailure("Failure! ggetThreadAllocatedBytes(id) should "
> 
> gget typo

Just an FYI that test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.testGetCurrentThreadAllocatedBytes also tests the same thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28673#discussion_r2591967408

From kevinw at openjdk.org  Fri Dec  5 09:30:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 5 Dec 2025 09:30:56 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
In-Reply-To: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
Message-ID: <ko78xOfdkb_NER6iZN8HNxbNlCT0Ia6Urwty6A4UXsM=.f7f6137c-6d1a-4cb1-8b63-464ffe275585@github.com>

On Fri, 5 Dec 2025 06:34:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
> 
> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
> 
> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/BaseBehaviorTest.java line 68:

> 66:                 throw new TestFailure("Failure! getCurrentThreadAllocatedBytes() should "
> 67:                     + "return -1 for virtual thread. "
> 68:                     + "Recieved : " + result);

typo, received is correct.  We have a lot of existing incorrect "recieved" spelling in this file 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28673#discussion_r2591992401

From kevinw at openjdk.org  Fri Dec  5 09:57:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 5 Dec 2025 09:57:02 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
In-Reply-To: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
Message-ID: <4DPwNFMQizSLC39wvWmY5UgjDfbIPcKqsO_g7fAqTVM=.187d3eee-eddc-4742-ad69-dcc1477c03d2@github.com>

On Fri, 5 Dec 2025 06:34:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
> 
> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
> 
> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

Looks good, would be nice to fix the existing spelling problems. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28673#pullrequestreview-3543939582

From schernyshev at openjdk.org  Fri Dec  5 10:27:43 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 5 Dec 2025 10:27:43 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v9]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <NQrWjD50AOqziH4_L2YeWaCxPRSVhP_OvOFHz434-jY=.61d066da-6a88-4cbc-b987-076e5027ca5c@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - Reapply "8319589: Attach from root to a user java process not supported in Mac" consolidated as a single patch, with reviewers suggestions.
 - Revert "8319589: Attach from root to a user java process not supported in Mac"
   
   This reverts commit 9fd3781d73286fadf971ab0b6fcc231fba008c94.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/fd1645b0..1dd07e6f

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

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

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

From schernyshev at openjdk.org  Fri Dec  5 10:27:45 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 5 Dec 2025 10:27:45 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
 <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>
Message-ID: <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>

On Thu, 4 Dec 2025 00:31:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed review comments
>
> We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module.
> We got the following concerns:
>  - Do we really need 3x implementations of the MacOS `tempdir` finder function?
>  - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`?
> New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
> My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
> Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this.

Hi @sspitsyn ,

Thank you for looking at this patch!

> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions?

The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root.

> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.

The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory.

> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct?

I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux).

> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS?

Yes and this is what this patch was intended for.

>     * Do we really need 3x implementations of the MacOS `tempdir` finder function?

It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to.

>     * Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`?

It was already a dependency of `jdk.attach` to `sun.jvmstat.monitor`. This change exports also `sun.jvmstat`, in addition to `sun.jvmstat.monitor` as it was before.

> src/hotspot/os/bsd/os_bsd.cpp line 956:
> 
>> 954: }
>> 955: #endif
>> 956: 
> 
> Nit: I'd suggest to get rid of empty lines which do not improve readability:
>  890, 903, 908, 917, 923, 930, 933, 941, 944
>  Also, the comment at line 931 is better to start with a capital letter: `// If the ..` .

Thanks @sspitsyn , done.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3616052858
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2592160722

From bkilambi at openjdk.org  Fri Dec  5 10:55:01 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 5 Dec 2025 10:55:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <xnv1Opu5mYuEW8QCbg9LJm7O9CWGrKD9t4mI-EOALgU=.1ea2fb88-bbd8-4ce1-bd3d-6b5289f146e5@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups

src/hotspot/share/opto/vectorIntrinsics.cpp line 341:

> 339:       laneType     == nullptr || !laneType->is_con() ||
> 340:       vector_klass == nullptr || vector_klass->const_oop() == nullptr ||
> 341:       laneType     == nullptr || !laneType->is_con() ||

is this repeating the same condition on line 339?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2592254926

From jsikstro at openjdk.org  Fri Dec  5 11:07:34 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 5 Dec 2025 11:07:34 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur [v2]
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <-L0gaSPwkSX8qo76PKGskcQ7cyfcNPBXEKBs65ZWgWU=.7d461216-afc3-4c6b-a424-c30478a35c58@github.com>

> Hello,
> 
> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
> 
> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
> 
> Testing: 
> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.

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

 - Remove ClhsdbScanOops.java from ProblemList
 - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
 - Remove InitialHeapSize from MethodInvokeWithTraceOnTest
 - Spell fix
 - 8373022: Increase initial heap size for test which assumes no GC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28637/files
  - new: https://git.openjdk.org/jdk/pull/28637/files/97f53447..0f85529d

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

  Stats: 8457 lines in 271 files changed: 6033 ins; 1546 del; 878 mod
  Patch: https://git.openjdk.org/jdk/pull/28637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28637/head:pull/28637

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

From jsikstro at openjdk.org  Fri Dec  5 11:07:35 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 5 Dec 2025 11:07:35 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur
In-Reply-To: <iZ2T20L23hOaeyfV0Ya1Xq1obnOktWOzvZ5QpX-50qk=.9c4efa2c-4062-4a73-9e44-7def9d94a3f1@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <iZ2T20L23hOaeyfV0Ya1Xq1obnOktWOzvZ5QpX-50qk=.9c4efa2c-4062-4a73-9e44-7def9d94a3f1@github.com>
Message-ID: <QxTmNFULRrtHdyCsCREdvwMZW_b6uVELZJ_U49E88Ag=.0ae541d6-0a14-4d51-b6f4-8109c31d4d0f@github.com>

On Thu, 4 Dec 2025 17:12:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hello,
>> 
>> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
>> 
>> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
>> 
>> Testing: 
>> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.
>
>> > It's probably just the timing of the GC that determines whether the initial small heap is a problem or not. If you want the SA tests to be reliable with something like InitialRAMPercentage=0, probably all of the tests should be updated. However, personally I don't think this type of fix should be necessary unless you feel testing in the manner is something we want to support. There are plenty of tests that start failing when non-standard command line options are used.
>> 
>> FYI we just integrated a change that sets InitialRAMPercentage=0 for JDK 26 that we've been working on (see #28641). We've run up to Oracle's tier8 twice now, and apart from the tests that are included in this PR, we've not seen any other SA failures.
>> 
>> Of course there might be other intermittent failures in the future, in which case I see two approaches moving forward: problem listing or bumping the initial heap size for the affected tests, or going over all SA tests and making sure that they all run with a "large" initial heap size (like 100MB). Unless we start seing many (for some definition of many) test failures from now, a pragmatic compromise is to selectively bump the initial heap size of such tests, like I do in this PR.
>> 
>> Of course, the optimal approach would be to make any affected SA tests more robst to GC timings. But, since I'm not sure how much time we want to invest in improving SA tests, bumping the heap size is likely a good compromise here.
> 
> For the most part the SA tests are fine if there is a GC. The way they usually work is to launch the debuggee, wait for it to reach a stable point (all threads idle), and then start to query the debuggee. If a GC happens before reaching stability, that should be fine, and after stability we wouldn't expect any GCs no matter what the heap size is. There are some SA tests that run on active processes where GCs can happen, but they are written to allow for errors.

Thank you @plummercj for analysing the tests. I've removed the explicit InitialHeapSize from test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java in favor of https://github.com/openjdk/jdk/pull/28666. I've also removed test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java from the ProblemList.

The two sets of tests that are associated with this issue but not addressed in this PR are about to be solved in https://github.com/openjdk/jdk/pull/28666 and https://github.com/openjdk/jdk/pull/28655. I'm holding off on this PR until those changes are integrated.

I've updated both the issue and this PR to reflect the new changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3616404117

From cjplummer at openjdk.org  Fri Dec  5 15:38:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 15:38:51 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur [v2]
In-Reply-To: <-L0gaSPwkSX8qo76PKGskcQ7cyfcNPBXEKBs65ZWgWU=.7d461216-afc3-4c6b-a424-c30478a35c58@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <-L0gaSPwkSX8qo76PKGskcQ7cyfcNPBXEKBs65ZWgWU=.7d461216-afc3-4c6b-a424-c30478a35c58@github.com>
Message-ID: <G5-e4IIYEqE4K-h0fxz497HSJO49W4VRJVeDMyiMHzo=.162bbfd5-631d-4190-b037-cc7771c94cee@github.com>

On Fri, 5 Dec 2025 11:07:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
>> 
>> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
>> 
>> Testing: 
>> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Remove ClhsdbScanOops.java from ProblemList
>  - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
>  - Remove InitialHeapSize from MethodInvokeWithTraceOnTest
>  - Spell fix
>  - 8373022: Increase initial heap size for test which assumes no GC

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28637#pullrequestreview-3545287313

From cjplummer at openjdk.org  Fri Dec  5 15:43:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 15:43:23 GMT
Subject: RFR: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap [v2]
In-Reply-To: <ci9Fl6dVXTz4egGcnK_4sm0b129UUufvCtpkMUA-yPM=.232e771f-93b9-406c-bfe7-eb2ec494c921@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
 <ci9Fl6dVXTz4egGcnK_4sm0b129UUufvCtpkMUA-yPM=.232e771f-93b9-406c-bfe7-eb2ec494c921@github.com>
Message-ID: <2u6QgF7lwnKf_lZYIMaach2eTRuztgGccXDgZ59RNAc=.34e7e2d7-df9d-470a-a93e-7d23519af9a0@github.com>

On Fri, 5 Dec 2025 01:14:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
>> 
>> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better implementation

Thank you for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28666#issuecomment-3617415711

From cjplummer at openjdk.org  Fri Dec  5 15:43:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 15:43:24 GMT
Subject: Integrated: 8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can
 fail with ObjectCollectedException when run with a small heap
In-Reply-To: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
References: <epDkd1mq6as7oeffihrtj8SIc7xwev-qwhGBsQbRBKc=.173feaa4-2f56-465a-8137-5d55f7f93838@github.com>
Message-ID: <XhcxsExOIkagSe0z-v3VnjXdfz79whgxY54XofEMnlw=.7d9d93b2-8ce3-4442-8179-415f0bc0bc01@github.com>

On Thu, 4 Dec 2025 21:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> With JDI tracing enabled, an attempt to trace an event when using SUSPEND_NONE can result in an ObjectCollectedException because the thread is still running and objects that are part of the trace can be collected already. In this case were were dealing with trying to print the thread name for a VirtualThreadEndEvent, and the virtual thread has already exited and been gc'd.
> 
> Tested by running test case before change (verified failure) and after change (50 runs without a failure). Will also run tier1 and tier5 svc just to be sure.

This pull request has now been integrated.

Changeset: ee0b8a72
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee0b8a72c64f7ac5058dbe5b2062cb35b6195484
Stats:     18 lines in 2 files changed: 14 ins; 1 del; 3 mod

8373102: com/sun/jdi/MethodInvokeWithTraceOnTest.java can fail with ObjectCollectedException when run with a small heap

Reviewed-by: amenkov, sspitsyn

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

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

From ayang at openjdk.org  Fri Dec  5 15:46:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 15:46:30 GMT
Subject: RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
References: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
Message-ID: <6gizJUxJNd9e4dhptrMUbDyr0SOm9yDGL9wTSe1nl3Y=.916cf937-5055-402a-96e7-eaf18e79aa6e@github.com>

On Thu, 4 Dec 2025 09:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The original intended fix is to increase initial-heap-size so avoid gc, captured in [JDK-8373022](https://bugs.openjdk.org/browse/JDK-8373022). This is an alternative, which makes the test more resilient to changes in heaps/gcs.
> 
> Running `vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded002/TestDescription.java`
> with `-XX:+UseParallelGC -Xcomp -XX:-TieredCompilation -XX:InitialRAMPercentage=0` fails about 10% of the time.
> 
> After applying the fix, `isexceeded002` passes 2,000 runs.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28655#issuecomment-3617433211

From ayang at openjdk.org  Fri Dec  5 15:49:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 15:49:42 GMT
Subject: Integrated: 8373086: Make isexceeded001.java more robust
In-Reply-To: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
References: <m_5ZFAROHm86XhzvimYIgM0Z7P4SVICC8732SQwh4_E=.58a51c06-569b-4144-9d4b-2a1a02670b27@github.com>
Message-ID: <O1ATFRAXzz57iCROgzNpxF4zA3O4Nh9f-OdzjTQNMYI=.a3e4f44f-9e8b-40ca-8ee5-09614c7ea12e@github.com>

On Thu, 4 Dec 2025 09:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The original intended fix is to increase initial-heap-size so avoid gc, captured in [JDK-8373022](https://bugs.openjdk.org/browse/JDK-8373022). This is an alternative, which makes the test more resilient to changes in heaps/gcs.
> 
> Running `vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded002/TestDescription.java`
> with `-XX:+UseParallelGC -Xcomp -XX:-TieredCompilation -XX:InitialRAMPercentage=0` fails about 10% of the time.
> 
> After applying the fix, `isexceeded002` passes 2,000 runs.

This pull request has now been integrated.

Changeset: 4d696d0d
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d696d0d0ed523e3c99c68214586673913b1c7b5
Stats:     8 lines in 2 files changed: 1 ins; 6 del; 1 mod

8373086: Make isexceeded001.java more robust

Reviewed-by: jsikstro, tschatzl

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

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

From jsikstro at openjdk.org  Fri Dec  5 15:59:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 5 Dec 2025 15:59:07 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur [v2]
In-Reply-To: <-L0gaSPwkSX8qo76PKGskcQ7cyfcNPBXEKBs65ZWgWU=.7d461216-afc3-4c6b-a424-c30478a35c58@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <-L0gaSPwkSX8qo76PKGskcQ7cyfcNPBXEKBs65ZWgWU=.7d461216-afc3-4c6b-a424-c30478a35c58@github.com>
Message-ID: <3hmPowVDF4TkIMalmgNIFk7Q7AYPnAAr4xDXgXolc5E=.f101c300-8cf5-4b5f-b334-f780a6ed6a0c@github.com>

On Fri, 5 Dec 2025 11:07:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
>> 
>> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
>> 
>> Testing: 
>> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Remove ClhsdbScanOops.java from ProblemList
>  - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
>  - Remove InitialHeapSize from MethodInvokeWithTraceOnTest
>  - Spell fix
>  - 8373022: Increase initial heap size for test which assumes no GC

After merging with master and considering the change in this PR, no more tests referencing this issue are problem listed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3617477024

From jsikstro at openjdk.org  Fri Dec  5 15:59:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 5 Dec 2025 15:59:03 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur [v3]
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <mQJLdyyYUpFOd4JobeFsLSQZ-bVRBXgUHDsLQj8-NQs=.ce2bc63d-c6a3-40f5-9a33-69cfff71fa42@github.com>

> Hello,
> 
> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
> 
> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
> 
> Testing: 
> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.

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

 - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
 - Remove ClhsdbScanOops.java from ProblemList
 - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
 - Remove InitialHeapSize from MethodInvokeWithTraceOnTest
 - Spell fix
 - 8373022: Increase initial heap size for test which assumes no GC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28637/files
  - new: https://git.openjdk.org/jdk/pull/28637/files/0f85529d..5a8561aa

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

  Stats: 35 lines in 5 files changed: 15 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28637/head:pull/28637

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

From lmesnik at openjdk.org  Fri Dec  5 16:09:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Dec 2025 16:09:29 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing [v2]
In-Reply-To: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
Message-ID: <6UlslEQoGUzvqcbuLg5QvUYJ-FjNh4_wuZevbFM-t4g=.f4ba743d-60cc-4381-ad19-3692527b3ad8@github.com>

> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
> 
> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
> 
> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28673/files
  - new: https://git.openjdk.org/jdk/pull/28673/files/82403c63..4d09cd20

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

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

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

From ayang at openjdk.org  Fri Dec  5 16:18:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 16:18:01 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
Message-ID: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>

Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.

`runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.

After the revert, the test passes 2K runs.

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

Commit messages:
 - Revert "8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch"

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

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

From mdoerr at openjdk.org  Fri Dec  5 16:33:10 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 5 Dec 2025 16:33:10 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <kVxSIzA82tl_oFjO97zHeLzpOlSrvtMpzeQkwBx6JBk=.a8e5783e-27fd-4275-8014-dcd346552548@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Backout is correct (clean).

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28679#pullrequestreview-3545488972

From kevinw at openjdk.org  Fri Dec  5 16:57:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 5 Dec 2025 16:57:33 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing [v2]
In-Reply-To: <6UlslEQoGUzvqcbuLg5QvUYJ-FjNh4_wuZevbFM-t4g=.f4ba743d-60cc-4381-ad19-3692527b3ad8@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
 <6UlslEQoGUzvqcbuLg5QvUYJ-FjNh4_wuZevbFM-t4g=.f4ba743d-60cc-4381-ad19-3692527b3ad8@github.com>
Message-ID: <zOv3nNEd6fkib2C0K5kNbokUoYTpIMuukFhB5aTfA7I=.2abcd3b4-3a0a-4676-8f79-026b9e0ce437@github.com>

On Fri, 5 Dec 2025 16:09:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
>> 
>> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
>> 
>> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typos

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28673#pullrequestreview-3545589224

From kvn at openjdk.org  Fri Dec  5 17:20:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 5 Dec 2025 17:20:56 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <ti5ZnuL9vvYHPsmHL9jOqc8_2S9HWKEwHY8AOaAejxU=.aeba4867-b8e6-4994-8de4-6d2ef6696091@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28679#pullrequestreview-3545668409

From ayang at openjdk.org  Fri Dec  5 19:20:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 19:20:12 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <u73wLCBJ4gBOn9Z-UQqsxWXWav2ILNbSt6InF3Od_qc=.c89256c7-2686-4171-94a5-c4e709230d94@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Thanks for review. Merging now to resolve CI failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/28679#issuecomment-3618235905

From ayang at openjdk.org  Fri Dec  5 19:20:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 19:20:13 GMT
Subject: Integrated: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <yJUmj5QMXJUQv1YGYp0msZs4aAaJo0OwKeuLf7tOzUE=.e2261367-aef9-419e-9491-aacb4cdf167e@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

This pull request has now been integrated.

Changeset: 43787890
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a
Stats:     69 lines in 7 files changed: 66 ins; 0 del; 3 mod

8373145: [BACKOUT] Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch

Reviewed-by: mdoerr, kvn

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

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

From cjplummer at openjdk.org  Fri Dec  5 20:38:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 20:38:58 GMT
Subject: RFR: 8370846: Support execution of mlvm testing with test thread
 factory [v2]
In-Reply-To: <X1feeokzFqaRRGQw5rmR37RXCri69LCS1R7j_02KOVw=.036ca803-e409-4875-af5e-7868d144eac4@github.com>
References: <mASl_0Bbtw8ht-HYde1GspqbZ_foRaQ7OUHuF3oPetQ=.67dee430-f96d-439b-80f6-ff48f1346223@github.com>
 <X1feeokzFqaRRGQw5rmR37RXCri69LCS1R7j_02KOVw=.036ca803-e409-4875-af5e-7868d144eac4@github.com>
Message-ID: <BA4KvaftmxUjpTkY8qjt1TtF85KYdMbVG4cBiQvcgmU=.b27757fa-bce9-42e3-b9d1-c65cdad9fb39@github.com>

On Tue, 28 Oct 2025 22:35:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The MainWrapper used test thread factory has generated lambda method. So the AbsentInformationException is expected.  The actual source path is not checked.
>> 
>> Tested by run mlvm tests with and without test thread factory.
>> 
>> Also
>> jdk/test/lib/thread/TestThreadFactory.java
>> updated to provide TestThreadFactory. isTestThreadFactorySet() 
>> that could be used by tests instead of checking property "test.thread.factory" directly.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved comment

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28028#pullrequestreview-3546371263

From cjplummer at openjdk.org  Fri Dec  5 20:40:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 20:40:12 GMT
Subject: RFR: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <ue1oCUnHNBsiXWKmVXYwr-uJxEve4uG6FM0He7NiHAE=.20f2c348-8050-42f1-ac7d-a9b85a4a161c@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28653#issuecomment-3618520995

From cjplummer at openjdk.org  Fri Dec  5 20:40:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 20:40:13 GMT
Subject: Integrated: 8362083: JDI VirtualMachine/dispose/dispose001 failed with
 FATAL ERROR in native method: JDWP cannot set thread local storage,
 jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
In-Reply-To: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
References: <y0tsJzELPSKZ6kfY1TNIMTRqTWp75SVTlyGw6C14Eng=.bfbe087a-6f98-476f-86f5-5e153dcab8de@github.com>
Message-ID: <nsbx7sVVV6tPsyJwu-QpjWaIv8FgvQTig2DAGel2bCM=.c17de244-01e5-470e-bc6d-969dc5252602@github.com>

On Thu, 4 Dec 2025 04:06:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> During the debugger disconnect we free all ThreadNodes for vthreads. Part of doing this includes calling JVMTI SetThreadLocalStorage(thread, NULL). It's possible that after the disconnect process has already started the VM starts to exit (resulting in a VMDeath event). Once this happens SetThreadLocalStorage will start to return JVMTI_ERROR_WRONG_PHASE. We should ignore this error rather than having it result in an fatal error for the debug agent.
> 
> Tested with tier1, all tier5 svc testing, and ran vmTestbase/nsk/jdi 10 times on linux-aarch64-debug, which is the only platform that has seen this failure so far.

This pull request has now been integrated.

Changeset: be8cbfa6
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be8cbfa6129d19403c9871c22721b902856f1886
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8362083: JDI VirtualMachine/dispose/dispose001 failed with FATAL ERROR in native method: JDWP cannot set thread local storage, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)

Reviewed-by: lmesnik, sspitsyn, amenkov

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

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

From cjplummer at openjdk.org  Fri Dec  5 20:55:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Dec 2025 20:55:55 GMT
Subject: RFR: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
In-Reply-To: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
References: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
Message-ID: <IAK_KBD4IUe5wDp0FcSX0AWU0Gx3X_Wc4X5elxEbHME=.95472714-ee42-4def-8b77-8c50687bc85d@github.com>

On Thu, 4 Dec 2025 02:07:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.
> 
> I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more to this bug.

Ping! Could use one more review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28652#issuecomment-3618571902

From lmesnik at openjdk.org  Fri Dec  5 21:23:08 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Dec 2025 21:23:08 GMT
Subject: Integrated: 8370846: Support execution of mlvm testing with test
 thread factory
In-Reply-To: <mASl_0Bbtw8ht-HYde1GspqbZ_foRaQ7OUHuF3oPetQ=.67dee430-f96d-439b-80f6-ff48f1346223@github.com>
References: <mASl_0Bbtw8ht-HYde1GspqbZ_foRaQ7OUHuF3oPetQ=.67dee430-f96d-439b-80f6-ff48f1346223@github.com>
Message-ID: <jONiMmzZyMb66-D5MePo6j1D5BqmcmvsNjOlyT0WlfA=.0f09d789-6d71-4c7b-91e6-c414862e2f89@github.com>

On Tue, 28 Oct 2025 21:06:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The MainWrapper used test thread factory has generated lambda method. So the AbsentInformationException is expected.  The actual source path is not checked.
> 
> Tested by run mlvm tests with and without test thread factory.
> 
> Also
> jdk/test/lib/thread/TestThreadFactory.java
> updated to provide TestThreadFactory. isTestThreadFactorySet() 
> that could be used by tests instead of checking property "test.thread.factory" directly.

This pull request has now been integrated.

Changeset: 2596608b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2596608ba1bb1b271dfa062bf732a5095e22fffd
Stats:     37 lines in 2 files changed: 32 ins; 0 del; 5 mod

8370846: Support execution of mlvm testing with test thread factory

Reviewed-by: cjplummer

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

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

From amenkov at openjdk.org  Fri Dec  5 22:31:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 5 Dec 2025 22:31:56 GMT
Subject: RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing [v2]
In-Reply-To: <6UlslEQoGUzvqcbuLg5QvUYJ-FjNh4_wuZevbFM-t4g=.f4ba743d-60cc-4381-ad19-3692527b3ad8@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
 <6UlslEQoGUzvqcbuLg5QvUYJ-FjNh4_wuZevbFM-t4g=.f4ba743d-60cc-4381-ad19-3692527b3ad8@github.com>
Message-ID: <ZWKaq0E0GDbAeRqVSL1ZX2UnQbtLd3B3LOoQpATVhwI=.45abc6f3-15a9-4e15-8869-ae69587a366a@github.com>

On Fri, 5 Dec 2025 16:09:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
>> 
>> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
>> 
>> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typos

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28673#pullrequestreview-3546633403

From lmesnik at openjdk.org  Sat Dec  6 00:06:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 6 Dec 2025 00:06:15 GMT
Subject: Integrated: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
In-Reply-To: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
References: <_ZJU1vglXYoyknDD95iRUE1nr7E7oVPLqCxgdUWwjh8=.b565ec67-fff2-49b8-a741-d1d63253529e@github.com>
Message-ID: <GJ2f-z9EQ3Do2qznBkKTIOLvaxP031Bh1OMCoOLx0_w=.5594930a-eb4d-422f-bba9-4c8d0adfe8c6@github.com>

On Fri, 5 Dec 2025 06:34:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adjust expected results for nsk/monitoring tests if they are executed with virtual threads or mark them as incompatible.
> 
> The ThreadInfo is not returned for virtual threads and some bean functions return -1.
> 
> Tested by running nsk/monitoring with JTREG_TEST_THREAD_FACTORY=Virtual

This pull request has now been integrated.

Changeset: b0f59f60
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0f59f6021a00dc569e08810b34db21553a5b68d
Stats:     87 lines in 7 files changed: 47 ins; 0 del; 40 mod

8373127: Update nsk/monitoring tests to support virtual thread factory testing

Reviewed-by: kevinw, amenkov

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

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

From duke at openjdk.org  Sat Dec  6 00:08:31 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Sat, 6 Dec 2025 00:08:31 GMT
Subject: RFR: 8369150:
 serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java failed with
 COH
Message-ID: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>

[JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)

The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. JVMTI events however are not guaranteed to be published before the JVM exits which can occasionally cause the test to fail. Instead of failing if the events are not receive the test was modified to print an error and pass. However, the test will still fail if the method fails to compile or if the nmethod fails to relocate.

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

Commit messages:
 - Fix NMethodRelocationTest

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

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

From ysuenaga at openjdk.org  Sun Dec  7 01:42:36 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 7 Dec 2025 01:42:36 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
Message-ID: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>

[JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.

This PR fixes it to implement `CFrame::toFrame`.

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

Commit messages:
 - Override 2 "sender" method in Bsd CFrame classes
 - 8373110: jstack --mixed frames are broken on macOS after JDK-8371194

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

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

From dyama at openjdk.org  Sun Dec  7 15:36:52 2025
From: dyama at openjdk.org (Daisuke Yamazaki)
Date: Sun, 7 Dec 2025 15:36:52 GMT
Subject: RFR: 8372949: ClassWriter.writeClassAttributes() can throw NPE
Message-ID: <SnAYnVLAYBVmPd9dLOU0ZC1VZ0Z4UdMifvtbkXrTLag=.67785903-d9b4-46f1-9c3b-e57623472e6c@github.com>

Hello maintainers,

This change prevents a possible NPE in [`ClassWriter.writeClassWttributes()`](https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java#L891).
[`ConstantPool.getBootstrapMethodAt()`](https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java#L479) now returns an empty array instead of `null` when no bootstrap methods are available.

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

Commit messages:
 - 8372949: Prevent NPE in getBootstrapMethodAt by returning an empty array for null offsets or bootstrap methods

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

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

From dholmes at openjdk.org  Sun Dec  7 22:43:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 7 Dec 2025 22:43:55 GMT
Subject: RFR: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
In-Reply-To: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
References: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
Message-ID: <skqw5fBBn2-flDO-nygHlgKYmyZhRoQ2_o3sVNzAdB0=.14f9675c-b1d1-4372-aad9-fd913941c330@github.com>

On Thu, 4 Dec 2025 02:07:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.
> 
> I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more to this bug.

Seems reasonable

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28652#pullrequestreview-3549669695

From dholmes at openjdk.org  Mon Dec  8 05:46:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Dec 2025 05:46:11 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
Message-ID: <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>

On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

I've completed a pass through everything and have a couple of comments on the functional changes.

The tests were quite hard to follow in places and I've flagged a few where you seemed to have done a more extensive rewrite than what was actually needed for the obsoletion - making it hard to assess the changes.

Thanks

src/hotspot/share/memory/metaspace.cpp line 661:

> 659:   MaxMetaspaceSize = MAX2(MaxMetaspaceSize, commit_alignment());
> 660: 
> 661:   if (using_class_space()) {

Shouldn't this now just be a build-time `ifdef _LP64` check?

src/hotspot/share/memory/metaspace.cpp line 728:

> 726:   }
> 727: 
> 728:   // a) if CDS is active (runtime, Xshare=on), it will create the class space

You have left descriptions of a) and b) but now we have no idea what they are referring to. ???

src/hotspot/share/runtime/arguments.cpp line 1591:

> 1589: 
> 1590:       size_t heap_end = HeapBaseMinAddress + MaxHeapSize;
> 1591:       size_t max_coop_heap = max_heap_for_compressed_oops();

Please don't change the types in this PR.

test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294:

> 292:     }
> 293: 
> 294:     public static void heapBaseMinAddressTestNoCoop() throws Exception {

It is not obvious to me why this test case was deleted.

test/hotspot/jtreg/runtime/ErrorHandling/TestVMConfigInHsErrFile.java line 59:

> 57:     switch (args[0]) {
> 58:       case "coh-on" -> testCompactObjectHeaders();
> 59:       case "coh-off" -> testCompressedClassPointers();

You seem to have done a complete test rewrite here and it is not obvious to me it follows as part of the obsoletion of UCCP.

test/hotspot/jtreg/runtime/cds/appcds/TestCombinedCompressedFlags.java line 67:

> 65:         private void initExecArgs() {
> 66:             // We fail this test if the UseCompressedOops setting used at dumptime differs from runtime,
> 67:             // succeed if it is identical

This test seems to reduce to pretty much nothing. ??

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 44:

> 42:     private final static String UNABLE_TO_USE_ARCHIVE = "Unable to use shared archive.";
> 43:     private final static String ERR_MSG = "The saved state of UseCompressedOops (0) is different from runtime (1), CDS will be disabled.";
> 44:     private final static String COMPACT_OBJECT_HEADERS = "-XX:+UseCompactObjectHeaders";

Again this test seems to have a lot of unrelated changes. This is obscuring the actual differences and makes the review harder.

test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 318:

> 316: 
> 317:     // Includes length, excludes alignment gap to base
> 318:     static final int ARRAY_HEADER_SIZE = Platform.is64bit() ? 16 : 12;

Again unrelated change.

test/jdk/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java line 75:

> 73:         final int bytesPerWord = runsOn32Bit ? 4 : 8;
> 74:         final int objectHeaderSize = runsOn32Bit ? 12 : 16;
> 75:         final int alignmentGap = runsOn32Bit ? 4 : 0;

Again unrelated changes.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3550086639
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597013211
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597014493
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597023027
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597045861
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597050708
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597102266
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597107079
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597110703
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597114451

From syan at openjdk.org  Mon Dec  8 08:01:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 8 Dec 2025 08:01:45 GMT
Subject: [jdk26] RFR: 8373086: Make isexceeded001.java more robust
Message-ID: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>

Hi all,

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

The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Joel Sikstr?m and Thomas Schatzl.

Thanks!

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

Commit messages:
 - Backport 4d696d0d0ed523e3c99c68214586673913b1c7b5

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

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

From syan at openjdk.org  Mon Dec  8 09:30:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 8 Dec 2025 09:30:36 GMT
Subject: [jdk26] RFR: 8373127: Update nsk/monitoring tests to support virtual
 thread factory testing
Message-ID: <iUpE9FJmiHV0ngFYLwUiNBjEHwSmD2REvMGoOYoH6ZY=.c0069613-6fd9-4502-bd4a-49195e77c327@github.com>

Hi all,

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

The commit being backported was authored by Leonid Mesnik on 6 Dec 2025 and was reviewed by Kevin Walls and Alex Menkov.

Thanks!

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

Commit messages:
 - Backport b0f59f6021a00dc569e08810b34db21553a5b68d

Changes: https://git.openjdk.org/jdk/pull/28695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373127
  Stats: 87 lines in 7 files changed: 47 ins; 0 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/28695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28695/head:pull/28695

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

From bkilambi at openjdk.org  Mon Dec  8 10:38:12 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 10:38:12 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups

test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:

> 132:                            .intoArray(output, i);
> 133:         }
> 134:         for (; i < LEN; i++) {

Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598040108

From epeter at openjdk.org  Mon Dec  8 10:43:01 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 10:43:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
Message-ID: <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>

On Mon, 8 Dec 2025 10:35:23 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups
>
> test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:
> 
>> 132:                            .intoArray(output, i);
>> 133:         }
>> 134:         for (; i < LEN; i++) {
> 
> Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?

Yes: there could be auto-vectorization.
No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?

It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598054314

From bkilambi at openjdk.org  Mon Dec  8 11:27:59 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 11:27:59 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
 <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
Message-ID: <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>

On Mon, 8 Dec 2025 10:39:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:
>> 
>>> 132:                            .intoArray(output, i);
>>> 133:         }
>>> 134:         for (; i < LEN; i++) {
>> 
>> Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?
>
> Yes: there could be auto-vectorization.
> No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?
> 
> It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.

Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598233546

From kevinw at openjdk.org  Mon Dec  8 11:44:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Dec 2025 11:44:29 GMT
Subject: RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
Message-ID: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>

Test is intended to run with a small new size, -Xmn8m
Without this, a larger new gen size means the allocations it make continually may never cause the Notification the test is waiting for.  Timeout interacts with the process and means some allocation, which does hit the threshold, so we see "Test passed." and a timeout in the same log.

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

Commit messages:
 - 8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

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

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

From iwalulya at openjdk.org  Mon Dec  8 13:31:12 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 8 Dec 2025 13:31:12 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
Message-ID: <zFfEexmtxjovY_ScXvsWxZSqMEzbN719AAMpC4b2PYI=.50a015c8-c7ae-4ec2-a4d4-4788b8e828da@github.com>

On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

src/hotspot/share/oops/instanceKlass.cpp line 492:

> 490:     assert(CompressedKlassPointers::is_encodable(ik),
> 491:            "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik));
> 492:   }

Suggestion:

  assert(ik == nullptr || CompressedKlassPointers::is_encodable(ik),
         "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik));

src/hotspot/share/oops/oop.inline.hpp line 104:

> 102:       return CompressedKlassPointers::decode_not_null(_metadata._compressed_klass);
> 103:     default:
> 104:       return _metadata._klass;

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 115:

> 113:       return CompressedKlassPointers::decode(_metadata._compressed_klass);
> 114:     default:
> 115:       return _metadata._klass;

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 128:

> 126:     }
> 127:     default:
> 128:       return AtomicAccess::load_acquire(&_metadata._klass);

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 139:

> 137:       return CompressedKlassPointers::decode_without_asserts(_metadata._compressed_klass);
> 138:     default:
> 139:       return _metadata._klass;

klass_mode() is either `Compact` or `Compressed`
Should be changed to:
Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 157:

> 155:   assert(Universe::is_bootstrapping() || (k != nullptr && k->is_klass()), "incorrect Klass");
> 156:   assert(!UseCompactObjectHeaders, "don't set Klass* with compact headers");
> 157:   _metadata._compressed_klass = CompressedKlassPointers::encode_not_null(k);

We might have to reconsider if we need to maintain the`union _metadata`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598158553
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598641735
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598409080
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598413848
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598407527
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598474672

From bkilambi at openjdk.org  Mon Dec  8 14:14:17 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 14:14:17 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <9l2GpacNaxOlYFPSJe-nRiAm1cPWcxYxg65R0o0ElgE=.59208f2f-df36-4eb3-93ac-62ada0eca4d6@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups

test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 82:

> 80:         output = new short[LEN];
> 81: 
> 82:         short min_value = float16ToRawShortBits(Float16.MIN_VALUE);

`min_value` and `max_value` not being used anywhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598793109

From ayang at openjdk.org  Mon Dec  8 14:29:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 14:29:12 GMT
Subject: [jdk26] RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
References: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
Message-ID: <M02eheJxui9YzJ8GBsN2JOdNCKIZMdyE-OpvUq-3PJc=.69f37ceb-c047-4195-b259-1ec009c4a94f@github.com>

On Mon, 8 Dec 2025 07:54:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d696d0d](https://github.com/openjdk/jdk/commit/4d696d0d0ed523e3c99c68214586673913b1c7b5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Joel Sikstr?m and Thomas Schatzl.
> 
> Thanks!

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28694#pullrequestreview-3552351963

From ayang at openjdk.org  Mon Dec  8 14:56:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 14:56:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
Message-ID: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>

[JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.

`TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.

Test: tier1-2

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

Commit messages:
 - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java

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

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

From cjplummer at openjdk.org  Mon Dec  8 15:38:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:38:50 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <e6yodTLLlqhJTWJKYVrrLKYu61ilZp3KDxlQyAL7dGo=.489d475a-9f9b-4f14-b5e8-3a28ca55de00@github.com>

On Mon, 8 Dec 2025 14:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

Copyright needs updating. Otherwise it looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/28700#pullrequestreview-3552670288

From cjplummer at openjdk.org  Mon Dec  8 15:41:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:41:17 GMT
Subject: RFR: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
In-Reply-To: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
References: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
Message-ID: <M6L-Yr_hfwLzpkU4k5A0sYGxMDo7gRCM3P6Ur0ycdeM=.f29ff743-d892-43be-9435-b06632096785@github.com>

On Thu, 4 Dec 2025 02:07:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.
> 
> I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more to this bug.

Thank you for the reviews David and Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/28652#issuecomment-3627536690

From cjplummer at openjdk.org  Mon Dec  8 15:41:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:41:17 GMT
Subject: Integrated: 8372555: Test com/sun/jdi/ExceptionEvents.java failed:
 ObjectCollectedException
In-Reply-To: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
References: <3Rs-0_uEEd-dVXSPINNbS61QE9ZlqT2FA6OMACuhsFg=.56f4faee-6578-4ad2-b078-272a498ed0a5@github.com>
Message-ID: <Ii205Hkrl-UYv8v9sdqeJj6m5bxmfwt00PIf9vIn-kk=.8a4a76c0-6a85-4034-b8ad-a31cca08a88d@github.com>

On Thu, 4 Dec 2025 02:07:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When the test receives an ExceptionEvent, the exception object can be collected if the SUSPEND_NONE policy is being used, resulting in an ObjectCollectedException when referencing event.exception(). The exception should be handled and not cause the test to fail.
> 
> I'm not sure if this fixes all the issues with 8372555. I suspect there is something else going on that has a side affect of triggering the collection of the exception object, but this is at least a first step towards figuring out if there is more to this bug.

This pull request has now been integrated.

Changeset: ac81ce51
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac81ce51fa4ed04b6dbcc28cb2dd8eabcfe52ad7
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8372555: Test com/sun/jdi/ExceptionEvents.java failed: ObjectCollectedException

Reviewed-by: amenkov, dholmes

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

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

From ayang at openjdk.org  Mon Dec  8 15:58:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 15:58:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28700/files
  - new: https://git.openjdk.org/jdk/pull/28700/files/67c306e4..1f70f90b

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

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

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

From cjplummer at openjdk.org  Mon Dec  8 15:58:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:58:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
 <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
Message-ID: <dEQSYNW8WY5nYVN813ptvIxqHdpbWox-VdjG5ppaLZo=.03160ac6-710e-490d-9954-a9cde1557085@github.com>

On Mon, 8 Dec 2025 15:55:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
>> 
>> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
>> 
>> Test: tier1-2
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28700#pullrequestreview-3552769993

From ayang at openjdk.org  Mon Dec  8 16:13:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 16:13:52 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
 <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
Message-ID: <Djo8YCABVsKCDq1zBzXbL2dghsUQFiazOIAKW4VTeag=.d888aaf4-af74-44cd-8028-58fd1e64a4f8@github.com>

On Mon, 8 Dec 2025 15:58:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
>> 
>> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
>> 
>> Test: tier1-2
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review. Merging now to reduce CI noise.

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

PR Comment: https://git.openjdk.org/jdk/pull/28700#issuecomment-3627760652

From ayang at openjdk.org  Mon Dec  8 16:13:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 16:13:53 GMT
Subject: Integrated: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <5xnAvzMSfARGEbCbhXs5vPoGEKbwX8EIT7D8olpx9hs=.28e899fd-0722-4e3a-bc48-be5fc42eba46@github.com>

On Mon, 8 Dec 2025 14:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

This pull request has now been integrated.

Changeset: 811591c5
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/811591c5c332e6427dc96819451e046841fe635b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8373262: Parallel: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails

Reviewed-by: cjplummer

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

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

From lmesnik at openjdk.org  Mon Dec  8 16:59:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Dec 2025 16:59:39 GMT
Subject: RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
References: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
Message-ID: <6QrZXcskwBD0KeJWaR-QRBI1cvRIverqlp_8-dItJuk=.5b3f2953-4bf3-41d8-ab03-3b34820c4ad4@github.com>

On Mon, 8 Dec 2025 11:31:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test is intended to run with a small new size, -Xmn8m
> Without this, a larger new gen size means the allocations it make continually may never cause the Notification the test is waiting for.  Timeout interacts with the process and means some allocation, which does hit the threshold, so we see "Test passed." and a timeout in the same log.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28697#pullrequestreview-3553069968

From iklam at openjdk.org  Mon Dec  8 17:59:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 17:59:58 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3553358656

From shade at openjdk.org  Mon Dec  8 18:03:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 Dec 2025 18:03:23 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
Message-ID: <XnnLXSyOVGhdEXmbmpwxefIKo78eWSF0Wj129fHcshw=.7af07d6d-9ed8-4e20-bf0e-ce7727989ad4@github.com>

On Sat, 6 Dec 2025 02:35:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
> 
> This PR fixes it to implement `CFrame::toFrame`.

Drive-by comment:

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 108:

> 106:           boolean useCodeBlob = codeBlob != null && codeBlob.getFrameSize() > 0;
> 107:           nextSP = useCodeBlob ? nextFP.addOffsetTo((2 * ADDRESS_SIZE) - codeBlob.getFrameSize()) : nextFP;
> 108:         }                                                                         }

Suggestion:

        }
      }

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

PR Review: https://git.openjdk.org/jdk/pull/28686#pullrequestreview-3553362882
PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2599585391

From macarte at openjdk.org  Mon Dec  8 18:29:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 8 Dec 2025 18:29:02 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
 <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
Message-ID: <b1flBZPs6DeW7CEg1ggPW93o2IJQkO0d9pRba3J1wE0=.0663df75-cba3-47bd-8b3b-44287f84706a@github.com>

On Mon, 8 Dec 2025 17:57:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Looks good to me.

Thanks for the review and the documentation Ioi (I've updated the CSR); once Mark approves my updates based on his change requests we should be good to go.

Note that serviceability retargeted to jdk27 (they discussed this with me), this works for me although I know there's a process if we do want to hit JDK26 (given that we missed the first gate), let me know if there's consensus for pushing into JDK26

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628441123

From iklam at openjdk.org  Mon Dec  8 19:50:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 19:50:57 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <gUrT62X5ijdwfI_xFMDo8BwIOdLrjXxvFjwwiySZ8d4=.12beb30d-4922-4321-a49b-1abfb11f73fb@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

I think it's OK to integrate into the mainline (for 27) once you get an approval from Mark.

For JDK 26, I think we can following this process:
- https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

I'll try to update the JBS issue with a justification.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628741594

From cjplummer at openjdk.org  Mon Dec  8 20:39:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 20:39:56 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
Message-ID: <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>

On Sat, 6 Dec 2025 02:35:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
> 
> This PR fixes it to implement `CFrame::toFrame`.

macosx-aarch64 looks fine, but it looks like there is still an issue on macosx-x64. Stack traces are empty:

```----------------- 29955 -----------------
"Reference Handler" #15 daemon prio=10 tid=0x00007f94c0820010 nid=29955 waiting on condition [0x000070000e080000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ff803c3b6f6		????????

Before this change you at least got a partial stack followed by the UnsupportedPlatformException.

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3628901897

From schernyshev at openjdk.org  Mon Dec  8 21:34:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 8 Dec 2025 21:34:37 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v10]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <JPGc7Ta6ynI22ic12JkKS4Iw5lYeiwvuAkBWMFmdqTE=.de39a3b3-aef5-4a8a-a5bb-7da278b059c8@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/1dd07e6f..c318ac87

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

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

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

From ysuenaga at openjdk.org  Mon Dec  8 23:50:10 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 8 Dec 2025 23:50:10 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v2]
In-Reply-To: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
Message-ID: <gLxaqa4eoZ6rItyCXm0pTZoYr4BdyKqQWdwayXkcuZY=.36d12b41-a10e-4638-a658-cfc874f9945e@github.com>

> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
> 
> This PR fixes it to implement `CFrame::toFrame`.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28686/files
  - new: https://git.openjdk.org/jdk/pull/28686/files/bb892eb5..f5eeeaaf

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

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

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

From ysuenaga at openjdk.org  Mon Dec  8 23:50:11 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 8 Dec 2025 23:50:11 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>
Message-ID: <iW5HJT_ARfxoPzUxeMHCIVp3N6P82jd5tltspVySGcc=.87e8737e-43f6-4a91-978a-2c604818bcd4@github.com>

On Mon, 8 Dec 2025 20:37:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> macosx-aarch64 looks fine, but it looks like there is still an issue on macosx-x64. Stack traces are empty:
> 
> ```----------------- 29955 -----------------
> "Reference Handler" #15 daemon prio=10 tid=0x00007f94c0820010 nid=29955 waiting on condition [0x000070000e080000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_blocked
> 0x00007ff803c3b6f6		????????
> 
> Before this change you at least got a partial stack followed by the UnsupportedPlatformException.

@plummercj 

>  there is still an issue on macosx-x64. Stack traces are empty

Does it happen always? or intermittently?

> Before this change you at least got a partial stack followed by the UnsupportedPlatformException.

I'm not sure, but I guess jstack could not unwind frame at some point(s) due to unwind info like DWARF on Linux - jstack might not handle call frame because the symbol could not be resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3629519426

From cjplummer at openjdk.org  Mon Dec  8 23:50:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 23:50:12 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <iW5HJT_ARfxoPzUxeMHCIVp3N6P82jd5tltspVySGcc=.87e8737e-43f6-4a91-978a-2c604818bcd4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>
 <iW5HJT_ARfxoPzUxeMHCIVp3N6P82jd5tltspVySGcc=.87e8737e-43f6-4a91-978a-2c604818bcd4@github.com>
Message-ID: <k1GgneN7XIbGiFHeak3Su5Jjn_Jn_mVgIhUlK6RiRGw=.0b6aa2ae-02d5-441f-b4f8-a535705c5328@github.com>

On Mon, 8 Dec 2025 23:44:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Does it happen always? or intermittently?

Always. Every thread and with every run. All of the thread stack traces just have the one empty frame.

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3629527039

From ysuenaga at openjdk.org  Tue Dec  9 01:08:31 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Dec 2025 01:08:31 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
Message-ID: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>

> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
> 
> This PR fixes it to implement `CFrame::toFrame`.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Check RBP

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28686/files
  - new: https://git.openjdk.org/jdk/pull/28686/files/f5eeeaaf..a42f8f8b

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

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

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

From ysuenaga at openjdk.org  Tue Dec  9 01:08:32 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Dec 2025 01:08:32 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <k1GgneN7XIbGiFHeak3Su5Jjn_Jn_mVgIhUlK6RiRGw=.0b6aa2ae-02d5-441f-b4f8-a535705c5328@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>
 <iW5HJT_ARfxoPzUxeMHCIVp3N6P82jd5tltspVySGcc=.87e8737e-43f6-4a91-978a-2c604818bcd4@github.com>
 <k1GgneN7XIbGiFHeak3Su5Jjn_Jn_mVgIhUlK6RiRGw=.0b6aa2ae-02d5-441f-b4f8-a535705c5328@github.com>
Message-ID: <kZ4uLcFvQgbA22-nW9ERIafwudoKlSxHgCybX5PrdnI=.061961c1-0c2a-4d2f-b64e-b9d75ccd4110@github.com>

On Mon, 8 Dec 2025 23:47:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @plummercj 
>> 
>>>  there is still an issue on macosx-x64. Stack traces are empty
>> 
>> Does it happen always? or intermittently?
>> 
>>> Before this change you at least got a partial stack followed by the UnsupportedPlatformException.
>> 
>> I'm not sure, but I guess jstack could not unwind frame at some point(s) due to unwind info like DWARF on Linux - jstack might not handle call frame because the symbol could not be resolved.
>
>> Does it happen always? or intermittently?
> 
> Always. Every thread and with every run. All of the thread stack traces just have the one empty frame.

@plummercj Maybe it was fixed in the latest commit on this PR. Could you check again?

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3629736500

From cjplummer at openjdk.org  Tue Dec  9 02:44:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Dec 2025 02:44:54 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <k1GgneN7XIbGiFHeak3Su5Jjn_Jn_mVgIhUlK6RiRGw=.0b6aa2ae-02d5-441f-b4f8-a535705c5328@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <Fsv3Xoqq-BV-0-IJzCSBc4kBGc6cmTyv7_x_e4fQRDs=.3a2bf37f-10d5-44ea-86a9-3f94146dbe2c@github.com>
 <iW5HJT_ARfxoPzUxeMHCIVp3N6P82jd5tltspVySGcc=.87e8737e-43f6-4a91-978a-2c604818bcd4@github.com>
 <k1GgneN7XIbGiFHeak3Su5Jjn_Jn_mVgIhUlK6RiRGw=.0b6aa2ae-02d5-441f-b4f8-a535705c5328@github.com>
Message-ID: <oibaENKxJpy-UMwUEG1_-DGYSBnoWJFmimOdijiYkXg=.827446e8-b39e-4ed5-8fc1-01ffc569baa3@github.com>

On Mon, 8 Dec 2025 23:47:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @plummercj 
>> 
>>>  there is still an issue on macosx-x64. Stack traces are empty
>> 
>> Does it happen always? or intermittently?
>> 
>>> Before this change you at least got a partial stack followed by the UnsupportedPlatformException.
>> 
>> I'm not sure, but I guess jstack could not unwind frame at some point(s) due to unwind info like DWARF on Linux - jstack might not handle call frame because the symbol could not be resolved.
>
>> Does it happen always? or intermittently?
> 
> Always. Every thread and with every run. All of the thread stack traces just have the one empty frame.

> @plummercj Maybe it was fixed in the latest commit on this PR. Could you check again?

That seems to have fixed it. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3629958990

From cjplummer at openjdk.org  Tue Dec  9 04:03:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Dec 2025 04:03:56 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <MK_DxLISyD-ql6yJVRRCtR-NEVPO3gjOL_UrGZutRwM=.e102ad90-0de9-4479-ac47-adce26a13ae2@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 67:

> 65: 
> 66:    @Override
> 67:    public CFrame sender(ThreadProxy thread, Address nextSP, Address nextFP, Address nextPC) {

Why is it that for aarch64 these are all "next" arguments, but for AMD64 they are not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2600990445

From ysuenaga at openjdk.org  Tue Dec  9 04:20:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Dec 2025 04:20:57 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <MK_DxLISyD-ql6yJVRRCtR-NEVPO3gjOL_UrGZutRwM=.e102ad90-0de9-4479-ac47-adce26a13ae2@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
 <MK_DxLISyD-ql6yJVRRCtR-NEVPO3gjOL_UrGZutRwM=.e102ad90-0de9-4479-ac47-adce26a13ae2@github.com>
Message-ID: <ATQHb3N5oCWsyME_qOcyXF-_RDUExphXuwo3s7ZyJEQ=.cca8cfb5-fd1e-40ad-807f-bdec61c36c32@github.com>

On Tue, 9 Dec 2025 03:53:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check RBP
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 67:
> 
>> 65: 
>> 66:    @Override
>> 67:    public CFrame sender(ThreadProxy thread, Address nextSP, Address nextFP, Address nextPC) {
> 
> Why is it that for aarch64 these are all "next" arguments, but for AMD64 they are not?

I want to declare like `sender(ThreadProxy th, Address sp, Address fp, Address pc)` as defined in `CFrame`, however name of parameters (`sp`, `fp`, `pc`) have already declared as class members in `BsdAARCH64CFrame`. Thus I added `next` as a prefix of parameter name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2601028125

From cjplummer at openjdk.org  Tue Dec  9 05:55:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Dec 2025 05:55:57 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <ATQHb3N5oCWsyME_qOcyXF-_RDUExphXuwo3s7ZyJEQ=.cca8cfb5-fd1e-40ad-807f-bdec61c36c32@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
 <MK_DxLISyD-ql6yJVRRCtR-NEVPO3gjOL_UrGZutRwM=.e102ad90-0de9-4479-ac47-adce26a13ae2@github.com>
 <ATQHb3N5oCWsyME_qOcyXF-_RDUExphXuwo3s7ZyJEQ=.cca8cfb5-fd1e-40ad-807f-bdec61c36c32@github.com>
Message-ID: <aF1ZKEJFIqF7bH5FTMWoJ5Zi1Iw0xfvLvAo8GcZO-dw=.4c28ea7e-a4ab-4db4-93bc-8039b2901c5c@github.com>

On Tue, 9 Dec 2025 04:18:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 67:
>> 
>>> 65: 
>>> 66:    @Override
>>> 67:    public CFrame sender(ThreadProxy thread, Address nextSP, Address nextFP, Address nextPC) {
>> 
>> Why is it that for aarch64 these are all "next" arguments, but for AMD64 they are not?
>
> I want to declare like `sender(ThreadProxy th, Address sp, Address fp, Address pc)` as defined in `CFrame`, however name of parameters (`sp`, `fp`, `pc`) have already declared as class members in `BsdAARCH64CFrame`. Thus I added `next` as a prefix of parameter name.

Ok.  Looks like that was also the case with LunuxAARCH64CFrame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2601196616

From jbhateja at openjdk.org  Tue Dec  9 08:30:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Dec 2025 08:30:14 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v6]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <VAJhUqGSgwjChOnk92olPNL0IxBUJo5IdgpdWPZ7EBM=.5d730c53-51cf-49ea-b30a-eb8e260b674c@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Optimizing tail handling
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Fix failing jtreg test in CI
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - Fix some JTREG failures
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5f083aba...e830d855

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

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 509573 lines in 231 files changed: 281304 ins; 226541 del; 1728 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From jbhateja at openjdk.org  Tue Dec  9 08:30:15 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Dec 2025 08:30:15 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
 <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
 <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>
Message-ID: <C8jnZIttgoew84TwqmU58RtTmwq3hLUZMPx7a_qcL58=.0d5de984-2115-4fd2-a144-f06ed345da75@github.com>

On Mon, 8 Dec 2025 11:25:22 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Yes: there could be auto-vectorization.
>> No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?
>> 
>> It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.
>
> Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations?

@Bhavana-Kilambi vectorDim is a parameterizable parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2601582561

From sspitsyn at openjdk.org  Tue Dec  9 09:06:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Dec 2025 09:06:13 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
 <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>
 <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>
Message-ID: <WeGOmd3aSLLN6NF1pNgAMbfDkbviSb0xJDLVz1KKA44=.e04f69b8-efd4-42ea-84af-54e022eced37@github.com>

On Fri, 5 Dec 2025 09:42:51 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module.
>> We got the following concerns:
>>  - Do we really need 3x implementations of the MacOS `tempdir` finder function?
>>  - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`?
>> New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
>> My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
>> Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this.
>
> Hi @sspitsyn ,
> 
> Thank you for looking at this patch!
> 
>> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions?
> 
> The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root.
> 
>> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
> 
> The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory.
> 
>> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct?
> 
> I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux).
> 
>> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
> 
> Yes and this is what this patch was intended for.
> 
>>     * Do we really need 3x implementations of the MacOS `tempdir` finder function?
> 
> It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to.
> 
>>     * Do we really need a modular dependency f...

@sercher Thank you for the readability updates and answering questions!

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3631118258

From kevinw at openjdk.org  Tue Dec  9 09:21:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 9 Dec 2025 09:21:11 GMT
Subject: RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
References: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
Message-ID: <5VV1OFtkL2QyohmJxsjrfi-gWI-1TjA4Wd4Bj-iNQu4=.0b8a4a55-1e7f-448d-9cf2-2c22641910cf@github.com>

On Mon, 8 Dec 2025 11:31:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test is intended to run with a small new size, -Xmn8m
> Without this, a larger new gen size means the allocations it make continually may never cause the Notification the test is waiting for.  Timeout interacts with the process and means some allocation, which does hit the threshold, so we see "Test passed." and a timeout in the same log.

Thanks Leonid!

Tests OK on its own and in tier3.

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

PR Comment: https://git.openjdk.org/jdk/pull/28697#issuecomment-3631169177
PR Comment: https://git.openjdk.org/jdk/pull/28697#issuecomment-3631173234

From kevinw at openjdk.org  Tue Dec  9 09:21:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 9 Dec 2025 09:21:12 GMT
Subject: Integrated: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
References: <j_85YS1_KrFz3d_faTqfVikUMd-rveGJtrT3bYjuAJM=.13005cdc-babb-426d-93f5-dc6e959b85db@github.com>
Message-ID: <LwyaYojctXJLc-bbmmEDZoTj8Tva8GCdHEFkRMaWPmo=.c4970a9d-2aa0-45f8-ab70-152c6d958a16@github.com>

On Mon, 8 Dec 2025 11:31:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test is intended to run with a small new size, -Xmn8m
> Without this, a larger new gen size means the allocations it make continually may never cause the Notification the test is waiting for.  Timeout interacts with the process and means some allocation, which does hit the threshold, so we see "Test passed." and a timeout in the same log.

This pull request has now been integrated.

Changeset: 9c91c68d
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c91c68d1d5938d7e2b9a90c82b0a36ef1a063cd
Stats:     9 lines in 1 file changed: 4 ins; 3 del; 2 mod

8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

Reviewed-by: lmesnik

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

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

From jsikstro at openjdk.org  Tue Dec  9 09:47:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Dec 2025 09:47:12 GMT
Subject: RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC
 should occur [v3]
In-Reply-To: <mQJLdyyYUpFOd4JobeFsLSQZ-bVRBXgUHDsLQj8-NQs=.ce2bc63d-c6a3-40f5-9a33-69cfff71fa42@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
 <mQJLdyyYUpFOd4JobeFsLSQZ-bVRBXgUHDsLQj8-NQs=.ce2bc63d-c6a3-40f5-9a33-69cfff71fa42@github.com>
Message-ID: <o45nv8Q808e45x0TC0bxvJk5dQqk0iOTurTAv9JeQSE=.b6d95e3d-11ea-4bed-84ea-bf54230a5874@github.com>

On Fri, 5 Dec 2025 15:59:03 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
>> 
>> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
>> 
>> Testing: 
>> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
>  - Remove ClhsdbScanOops.java from ProblemList
>  - Merge branch 'master' into JDK-8373022_initialheapsize_test_no_gc
>  - Remove InitialHeapSize from MethodInvokeWithTraceOnTest
>  - Spell fix
>  - 8373022: Increase initial heap size for test which assumes no GC

Thank you for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3631278879

From jsikstro at openjdk.org  Tue Dec  9 09:47:13 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Dec 2025 09:47:13 GMT
Subject: Integrated: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no
 GC should occur
In-Reply-To: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
References: <71zAZi6kpYVYi5TCwj4fuOsqgjgoOksk8E3_Rs97J_Q=.faa53771-347d-4e60-97ff-1768d3f57363@github.com>
Message-ID: <uuLM7fjRhXy1r5R2BvwODyJpSa2yvYbP0E-gugK2W54=.2641b9aa-ed00-4698-89b7-1f0739cc0690@github.com>

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> If the initial heap size is set too low in serviceability/sa/ClhsdbScanOops.java, a GC migh run, which will interfere with the test and might cause it to fail. 
> 
> The test is scanning the oops in a region of the heap, and after a GC that region appears to be empty, so the output that the test expects is not present. Running the test with a larger explicit InitialHeapSize gives enough headroom to not run a GC.
> 
> Testing: 
> * serviceability/sa/ClhsdbScanOops.java originally failed when run with `-XX:InitialRAMPercentage=0` (which is the new default). We now explicitly set `-XX:InitialHeapSize=100M`. I've rerun the test 10 times with Serial and Parallel for each test and they all pass.

This pull request has now been integrated.

Changeset: 786833cd
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/786833cd1bf8eda1cef25da392a055f4eb371abf
Stats:     7 lines in 2 files changed: 3 ins; 3 del; 1 mod

8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC should occur

Reviewed-by: cjplummer, stefank, ayang, tschatzl

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

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

From jsikstro at openjdk.org  Tue Dec  9 12:49:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Dec 2025 12:49:00 GMT
Subject: [jdk26] RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
References: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
Message-ID: <6R-tSb3h3Ta8d-tlo_ttWt2FBUqZNbS6OCnC612ZQUw=.b99eda2e-d6b6-4337-8617-8e99498dc3fd@github.com>

On Mon, 8 Dec 2025 07:54:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d696d0d](https://github.com/openjdk/jdk/commit/4d696d0d0ed523e3c99c68214586673913b1c7b5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Joel Sikstr?m and Thomas Schatzl.
> 
> Thanks!

Marked as reviewed by jsikstro (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28694#pullrequestreview-3557235611

From cjplummer at openjdk.org  Tue Dec  9 16:47:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Dec 2025 16:47:48 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <Ckyqe6NPZNEEikI2wFPoasiHfnIQH8aS30PH2CiEu6g=.0f48914f-b149-4c11-968c-c1911f1631cd@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28686#pullrequestreview-3558478421

From thartmann at openjdk.org  Tue Dec  9 18:11:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:11:15 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
Message-ID: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>

Hi all,

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

The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.

Thanks!

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

Commit messages:
 - Backport 43787890291d71de61b28b8a4e3bf9aaba46757a

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

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

From chagedorn at openjdk.org  Tue Dec  9 18:11:15 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 18:11:15 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <MYUMYwCvr5M000McErM7EB2oVPyXAJgoDGMfWA_s5LA=.53c5ab3b-3934-42a0-adda-4e6ff7d12fd8@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28728#pullrequestreview-3558845542

From thartmann at openjdk.org  Tue Dec  9 18:14:08 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:14:08 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <O_vvAkgTs0slNJKua5L6UnOF5z_PlKUSNxegNS8AodQ=.8511daa1-0159-4f1b-9336-65bd4d9570d2@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

Thanks Christian!

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

PR Comment: https://git.openjdk.org/jdk/pull/28728#issuecomment-3633593617

From thartmann at openjdk.org  Tue Dec  9 18:40:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:40:27 GMT
Subject: [jdk26] Integrated: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <l602tdXGBu_ZZ_s033mQFnQXTr1KNQtzZYIqYD7dlRw=.e5523a1e-3ca1-42f8-9b29-c79ccda44d15@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bf0bc379
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf0bc37924b0c4f287d552253b63c06b9af5d5b5
Stats:     69 lines in 7 files changed: 66 ins; 0 del; 3 mod

8373145: [BACKOUT] Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch

Reviewed-by: chagedorn
Backport-of: 43787890291d71de61b28b8a4e3bf9aaba46757a

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

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

From cjplummer at openjdk.org  Wed Dec 10 01:28:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Dec 2025 01:28:55 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed with
 unexpected ObjectCollectedException
Message-ID: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>

The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.

This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.

Testing
- Tier1 CI
- Tier5 CI pruned to just run svc tests

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

Commit messages:
 - prevent thread from getting collected

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

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

From syan at openjdk.org  Wed Dec 10 02:17:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Dec 2025 02:17:51 GMT
Subject: [jdk26] Integrated: 8373086: Make isexceeded001.java more robust
In-Reply-To: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
References: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
Message-ID: <a1U9CsP-0U-lG0Ypq_jJr4aozcfxhF-NgNNjKf8IMV0=.60af46ce-ff70-41dd-95da-bf659dd4ed09@github.com>

On Mon, 8 Dec 2025 07:54:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d696d0d](https://github.com/openjdk/jdk/commit/4d696d0d0ed523e3c99c68214586673913b1c7b5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Joel Sikstr?m and Thomas Schatzl.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ec6beaa2
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec6beaa20adf808a14f6d4ebe7ee6be6ef494353
Stats:     8 lines in 2 files changed: 1 ins; 6 del; 1 mod

8373086: Make isexceeded001.java more robust

Reviewed-by: ayang, jsikstro
Backport-of: 4d696d0d0ed523e3c99c68214586673913b1c7b5

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

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

From syan at openjdk.org  Wed Dec 10 02:17:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Dec 2025 02:17:51 GMT
Subject: [jdk26] RFR: 8373086: Make isexceeded001.java more robust
In-Reply-To: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
References: <dl4KVNS8X6strou0-M7x_86wpomGKWiWLgMYrCFFg98=.ea894e15-07a0-4330-a8b2-98ccdec14c1a@github.com>
Message-ID: <X0McVhHiFmErHVKtlXF6iHQgdgoHpymktDXIAxfwCns=.1a0adb39-60cd-488b-8fda-eaecfff1e621@github.com>

On Mon, 8 Dec 2025 07:54:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d696d0d](https://github.com/openjdk/jdk/commit/4d696d0d0ed523e3c99c68214586673913b1c7b5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Joel Sikstr?m and Thomas Schatzl.
> 
> Thanks!

Change has been verified locally on linux-x64 by run the tests test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded00[1-5]/TestDescription.java. Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28694#issuecomment-3635055881

From sspitsyn at openjdk.org  Wed Dec 10 06:11:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Dec 2025 06:11:08 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
Message-ID: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>

This fixes the test which is unreliable and fails intermittently from time to time.
The test was failing in the method `checkReentrantLock()` when checking expected state with `vt.getState()`.
The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for details.
The fix is to add some sleep before call to the checkStates().

Testing:
 - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
 - TBD: submit mach5 tiers 1-3 to be completely safe

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

Commit messages:
 - 8371502: serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java failing

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

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

From sspitsyn at openjdk.org  Wed Dec 10 06:20:23 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Dec 2025 06:20:23 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
Message-ID: <qBPfMQnVG1_mGhtrbUq3UtowktQbNnJ4jh5FGHlBAlU=.ecbcc28d-f29d-4489-8cd7-040df9921f3d@github.com>

On Wed, 10 Dec 2025 06:00:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes the test which is unreliable and fails intermittently from time to time.
> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
> The fix is to add a big enough sleep before call to the checkStates().
> 
> Testing:
>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>  - TBD: submit mach5 tiers 1-3 to be completely safe

The most relevant test fragments are below:


    private static void checkReentrantLock() throws InterruptedException {
        final Thread.State expState = Thread.State.WAITING;
        reentrantLock.lock();
        String name = "ReentrantLockTestTask";
        TestTask task = new ReentrantLockTestTask();
        Thread vt = Thread.ofVirtual().name(name).start(task);
        task.ensureReady(vt, expState);
        checkStates(vt, expState); <== intermittently fails inside this call !!!
    } 

   private static void checkStates(Thread vt, Thread.State expState) {
        int singleState = getStateSingle(vt);
        int multiState = getStateMultiple(vt, Thread.currentThread());
        int jvmtiExpState = (expState == Thread.State.WAITING) ?
                            JVMTI_THREAD_STATE_WAITING :
                            JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER;

        System.out.printf("State: expected: %s single: %x multi: %x\n",
                          vt.getState(), singleState, multiState); <== printed state values !!!

        if (vt.getState() != expState) {         <== this comparison failed!!!
            failed("Java thread state is wrong");    <== Exception is thrown here!!!
        }
        . . .

class ReentrantLockTestTask extends TestTask {
    public void run() {
        log("grabbing reentrantLock");
        threadReady = true;
        ThreadListStackTracesTest.reentrantLock.lock(); <== May have waiting state in some class loading!
        log("grabbed reentrantLock");
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/28734#issuecomment-3635563778

From sspitsyn at openjdk.org  Wed Dec 10 08:48:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Dec 2025 08:48:07 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v2]
In-Reply-To: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
Message-ID: <pNFFq1GurFeUuzdYqwidcUBdlRSgK0VJeRlnK60EIkI=.86846a4b-e323-4f82-8f44-c7e1c3956a28@github.com>

> This fixes the test which is unreliable and fails intermittently from time to time.
> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
> The fix is to add a big enough sleep before call to the checkStates().
> 
> Testing:
>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>  - TBD: submit mach5 tiers 1-3 to be completely safe

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

  minor correction for sleep

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28734/files
  - new: https://git.openjdk.org/jdk/pull/28734/files/944164a7..38ad6eec

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

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

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

From jsikstro at openjdk.org  Wed Dec 10 09:57:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 10 Dec 2025 09:57:33 GMT
Subject: [jdk26] RFR: 8373022: serviceability/sa/ClhsdbScanOops.java assumes no
 GC should occur
Message-ID: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>

Hi all,

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

The commit being backported was authored by Joel Sikstr?m on 9 Dec 2025 and was reviewed by Chris Plummer, Stefan Karlsson, Albert Mingkun Yang and Thomas Schatzl.

Apart from the "clean" backport commit, I've changed the issue number for MethodInvokeWithTraceOnTest.java to [JDK-8373102](https://bugs.openjdk.org/browse/JDK-8373102), since the problem list is currently associated with this issue.

Thanks!

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

Commit messages:
 - Change ProblemList issue number
 - Backport 786833cd1bf8eda1cef25da392a055f4eb371abf

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

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

From stefank at openjdk.org  Wed Dec 10 09:57:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Dec 2025 09:57:33 GMT
Subject: [jdk26] RFR: 8373022: serviceability/sa/ClhsdbScanOops.java
 assumes no GC should occur
In-Reply-To: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
References: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
Message-ID: <_v8LeEbI0syTU06pMh8biGOKNhWYWptsJBNLAGKG414=.434b969b-0c51-4141-95e0-00aedbd35c39@github.com>

On Wed, 10 Dec 2025 09:31:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [786833cd](https://github.com/openjdk/jdk/commit/786833cd1bf8eda1cef25da392a055f4eb371abf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Joel Sikstr?m on 9 Dec 2025 and was reviewed by Chris Plummer, Stefan Karlsson, Albert Mingkun Yang and Thomas Schatzl.
> 
> Apart from the "clean" backport commit, I've changed the issue number for MethodInvokeWithTraceOnTest.java to [JDK-8373102](https://bugs.openjdk.org/browse/JDK-8373102), since the problem list is currently associated with this issue.
> 
> Thanks!

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28737#pullrequestreview-3561654726

From kevinw at openjdk.org  Wed Dec 10 10:19:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 10:19:42 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <pMD7Owj6ewGQigojywNhNi9qvddsQiqWdFE0zAg3Yfo=.97fc8ccd-92ac-4c23-8ce5-d9d5056069c5@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28730#pullrequestreview-3561763553

From kevinw at openjdk.org  Wed Dec 10 10:21:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 10:21:47 GMT
Subject: [jdk26] RFR: 8373022: serviceability/sa/ClhsdbScanOops.java
 assumes no GC should occur
In-Reply-To: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
References: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
Message-ID: <gEDS5ftnj8el8ggXe7spmHS0dZ2nNRdL8H01fad7VAw=.0184a5e4-5b19-4bb5-9e47-ebaccba7657a@github.com>

On Wed, 10 Dec 2025 09:31:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [786833cd](https://github.com/openjdk/jdk/commit/786833cd1bf8eda1cef25da392a055f4eb371abf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Joel Sikstr?m on 9 Dec 2025 and was reviewed by Chris Plummer, Stefan Karlsson, Albert Mingkun Yang and Thomas Schatzl.
> 
> Apart from the "clean" backport commit, I've changed the issue number for MethodInvokeWithTraceOnTest.java to [JDK-8373102](https://bugs.openjdk.org/browse/JDK-8373102), since the problem list is currently associated with this issue.
> 
> Thanks!

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28737#pullrequestreview-3561772052

From jbhateja at openjdk.org  Wed Dec 10 10:23:30 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 Dec 2025 10:23:30 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Optimizing tail handling
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Fix failing jtreg test in CI
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

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

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 515190 lines in 231 files changed: 284426 ins; 229037 del; 1727 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From sspitsyn at openjdk.org  Wed Dec 10 11:22:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Dec 2025 11:22:25 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <TFtBEgFkAYfaAeLnWLWfrOzaUD0Q0ZMqmPqsMl-eKUw=.4326c908-2708-403f-a841-25175d90fc3f@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

Good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28730#pullrequestreview-3562045796

From bkilambi at openjdk.org  Wed Dec 10 11:24:28 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 10 Dec 2025 11:24:28 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
Message-ID: <EZZJHvwvigZ6Fs9prEOVr8DGGtZbbxd1yxMf594q5Wc=.a05a98cc-c11f-4561-9922-a318217f4108@github.com>

On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Optimizing tail handling
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Fix failing jtreg test in CI
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
>  - Cleaning up interface as per review suggestions
>  - Some cleanups
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

This patch results in two of the JTREG tests failing on aarch64 machines-


jdk/incubator/vector/Float16Vector512Tests.java
compiler/vectorapi/TestFloat16VectorOperations.java


which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test.

@jatin-bhateja Could you please add the attached fix to this patch? Thanks!
[fix.patch](https://github.com/user-attachments/files/24076067/fix.patch)

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3636610190

From kevinw at openjdk.org  Wed Dec 10 14:49:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 14:49:32 GMT
Subject: RFR: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError
Message-ID: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>

This test has a number of issues, described in the note below.

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

Commit messages:
 - remove test option test
 - 8370731: Tests in vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed: OutOfMemoryError

Changes: https://git.openjdk.org/jdk/pull/28747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370731
  Stats: 44 lines in 5 files changed: 9 ins; 6 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/28747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28747/head:pull/28747

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

From kevinw at openjdk.org  Wed Dec 10 14:49:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 14:49:32 GMT
Subject: RFR: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError
In-Reply-To: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
References: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
Message-ID: <2iPmYy8BwwopnaPM4PIIziIUWJdVsUDCC-XUicjfd28=.10f072be-3319-47a2-8844-24617be9e637@github.com>

On Wed, 10 Dec 2025 14:33:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has a number of issues, described in the note below.

(1)
OOM has been showing up in testing occasionally, possibly forever.
Eventually got a failure due to OOM, took many runs.
It's G1 hitting "GC Overhead Limit exceeded too often (5)".

Should set UseGCOverheadLimit false as this is something of a stress test.

Verbose log shows:
[10.495s][info][gc] GC Overhead Limit exceeded too often (5).
----------System.err:(6/249)----------
java.lang.OutOfMemoryError: Java heap space


(2)
-XX:+DisableExplicitGC would break this test, as noted in its comment, so do not permit running with that option.

(3)
It can be too mysterious when tests print nothing about their work, unless they fail.  Are they even doing the work?
This test often (sometimes?) is not:
It eats memory, then does its validation only if stresser.continueExecution() is true.  This can be false and skip any testing.

So fix that with a do/while loop to ensure we validate at least once.

(4)
Then it failed immediately:  nsk.share.TestFailure: collectionCount not increased: 62 -> 62
It does not cope with iterations of the loop around the validation.
        
The only thing in validateNonTrivial() compared to the other validate() method, is ensuring collection count does increase, and this fails.
It needs to do the eat memory or invoke gc before checking that, so put eatMemory() inside the loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/28747#issuecomment-3637408913

From kevinw at openjdk.org  Wed Dec 10 15:47:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 15:47:33 GMT
Subject: [jdk26] RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
Message-ID: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>

8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

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

Commit messages:
 - Backport 9c91c68d1d5938d7e2b9a90c82b0a36ef1a063cd

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

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

From shade at openjdk.org  Wed Dec 10 17:12:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 17:12:22 GMT
Subject: [jdk26] RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
References: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
Message-ID: <Q513kpkxopr_Cr9mvqc-PZZ93Xcyu2zfmyew5UQPAdQ=.6a5049e7-e7d4-4b6d-82b4-490dcc86d2ac@github.com>

On Wed, 10 Dec 2025 15:25:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28749#pullrequestreview-3563628393

From kevinw at openjdk.org  Wed Dec 10 18:16:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 18:16:35 GMT
Subject: RFR: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError [v2]
In-Reply-To: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
References: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
Message-ID: <pLMXdyaaWSQfoukOfQleN7mVs2ad6kWgGqTyyg2EkgE=.d00564e5-98ea-478c-840f-876f7ba280c1@github.com>

> This test has a number of issues, described in the note below.

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28747/files
  - new: https://git.openjdk.org/jdk/pull/28747/files/e1ab1480..a6b3fda5

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

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

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

From mr at openjdk.org  Wed Dec 10 18:20:00 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 10 Dec 2025 18:20:00 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <0-DIQXf7yQXROjQZ82p1StLcHJiN4WwJU5A-uW1CVqw=.437dde89-0136-4afe-8641-8580abbf0697@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Marked as reviewed by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3563912082

From duke at openjdk.org  Wed Dec 10 18:41:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Dec 2025 18:41:32 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <abyii1o4tj07P6jyBf8GJK4rgSj0_1LAg8hr-tjM71M=.0baff849-cfac-4dd4-ab40-f85392471cf7@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

@macarte 
Your change (at version 8b0e27f26b94eb3f9e0c18b542f54da85e784121) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638450580

From macarte at openjdk.org  Wed Dec 10 18:52:05 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 10 Dec 2025 18:52:05 GMT
Subject: Integrated: 8369736 - Add management interface for AOT cache creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <0BIvIWfOQcKWZkhKpzxB6uJQC3caaKvqEeBzi7WU5b4=.b7c9874b-c5c8-4fec-ab7b-28df8457d88a@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

This pull request has now been integrated.

Changeset: 413f852b
Author:    Mat Carter <macarte at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/413f852bdb4767b2a1c29431144616668888138d
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: mr, iklam, kevinw

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

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

From kevinw at openjdk.org  Wed Dec 10 19:13:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 19:13:10 GMT
Subject: [jdk26] RFR: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
References: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
Message-ID: <LZiqoD2x7OdiJQU-9vp6u8HpUSiMlXQlU4Yj6L03waI=.d115f21c-2474-4131-8c61-7cc5b39442eb@github.com>

On Wed, 10 Dec 2025 15:25:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

Thanks Aleksey!

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

PR Comment: https://git.openjdk.org/jdk/pull/28749#issuecomment-3638568120

From kevinw at openjdk.org  Wed Dec 10 19:13:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Dec 2025 19:13:11 GMT
Subject: [jdk26] Integrated: 8373111: Test
 java/lang/management/MemoryMXBean/MemoryManagement.java timed out
In-Reply-To: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
References: <bccqfJxa1lQKP1WkDcQIOyRHd8aRNMAIcneTwFqOrVc=.e3b1fed2-b39e-4583-9039-0138f14d45ca@github.com>
Message-ID: <3Cw8WDTwS4GsnDuceDog_b6_kBRcK3x8kO1YTmDRnoA=.10472b39-cd37-4926-b825-1ebc6b34a159@github.com>

On Wed, 10 Dec 2025 15:25:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

This pull request has now been integrated.

Changeset: 7dc8f786
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7dc8f786fe50ee96dd9bfe01e18a81d24f04a1fc
Stats:     9 lines in 1 file changed: 4 ins; 3 del; 2 mod

8373111: Test java/lang/management/MemoryMXBean/MemoryManagement.java timed out

Reviewed-by: shade
Backport-of: 9c91c68d1d5938d7e2b9a90c82b0a36ef1a063cd

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

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

From iklam at openjdk.org  Wed Dec 10 19:18:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 19:18:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <IT6BSYlxvqy2lOZon0SewMkGwdEIlCwONU488cI5adU=.137c96b4-20f5-48f4-8793-22a932f61ed4@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

FYI, I've added a request to include this in JDK 26.

- https://bugs.openjdk.org/browse/JDK-8369736?focusedId=14840372&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14840372

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638593964

From sspitsyn at openjdk.org  Wed Dec 10 20:34:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Dec 2025 20:34:35 GMT
Subject: RFR: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError [v2]
In-Reply-To: <pLMXdyaaWSQfoukOfQleN7mVs2ad6kWgGqTyyg2EkgE=.d00564e5-98ea-478c-840f-876f7ba280c1@github.com>
References: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
 <pLMXdyaaWSQfoukOfQleN7mVs2ad6kWgGqTyyg2EkgE=.d00564e5-98ea-478c-840f-876f7ba280c1@github.com>
Message-ID: <a2SKJ1G5QlyS04ETjjZRNwiGEv9Go_8gr6uIP9HbklQ=.ff34b716-8929-40ce-ab58-afc225236b8a@github.com>

On Wed, 10 Dec 2025 18:16:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test has a number of issues, described in the note below.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Looks okay.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28747#pullrequestreview-3564368916

From amenkov at openjdk.org  Wed Dec 10 21:00:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Dec 2025 21:00:37 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <aLrRHxbmuQkSUylTFcV9Yf7K8J7EWjgvynep-U069DE=.dc6ec5f3-c8c0-4b54-82e0-aea96a87a9e8@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28730#pullrequestreview-3564449365

From dholmes at openjdk.org  Wed Dec 10 21:05:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 21:05:53 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <X13ctyRpg3UL3UD_kvGh7OtXqeX7M4rH75L12fhwmro=.925e29a0-a26b-446d-b010-9912ecd80943@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

This change has broken the "since" checker test: tools/sincechecker/modules/jdk.management/JdkManagementCheckSince.java

src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:44 class: jdk.management.HotSpotAOTCacheMXBean: `@since` version: 26; should be: 27
src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:92 method: boolean jdk.management.HotSpotAOTCacheMXBean.endRecording(): `@since` version: 26; should be: 27
java.lang.Exception: The `@since` checker found 2 problems

Bug being filed

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638949417

From kvn at openjdk.org  Wed Dec 10 21:30:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 10 Dec 2025 21:30:09 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <LEJm3sKWe3Rkb-JadJ1BgoqpLZWiDc2psjfkHVNgdH0=.c2ca2cc8-fa90-4355-8f27-4b190812f596@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

At least current code will be simple to backport to 26.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3639029804

From lmesnik at openjdk.org  Thu Dec 11 00:57:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 11 Dec 2025 00:57:22 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v2]
In-Reply-To: <pNFFq1GurFeUuzdYqwidcUBdlRSgK0VJeRlnK60EIkI=.86846a4b-e323-4f82-8f44-c7e1c3956a28@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <pNFFq1GurFeUuzdYqwidcUBdlRSgK0VJeRlnK60EIkI=.86846a4b-e323-4f82-8f44-c7e1c3956a28@github.com>
Message-ID: <NHnlVqfYZ3jCk8WWouoF_4sMl27WR2YLS47Xtqf5nBA=.59cd490d-10e9-46e3-af0b-abb419884123@github.com>

On Wed, 10 Dec 2025 08:48:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor correction for sleep

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 100:

> 98:         TestTask task = new ReentrantLockTestTask();
> 99:         Thread vt = Thread.ofVirtual().name(name).start(task);
> 100:         TestTask.sleep(50); // allow potentially needed class loading to complete

The  just sleep might be unreliable.

Would it makes sense to wait until `lock.hasQueuedThreads()` becomes true?

If 'hasQueuedThreads' doesn't work then makes to pre-load classes used by lock before running test.

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

PR Review: https://git.openjdk.org/jdk/pull/28734#pullrequestreview-3565186542
PR Review Comment: https://git.openjdk.org/jdk/pull/28734#discussion_r2608755950

From sspitsyn at openjdk.org  Thu Dec 11 02:36:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Dec 2025 02:36:12 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
Message-ID: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>

> This fixes the test which is unreliable and fails intermittently from time to time.
> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
> The fix is to add a big enough sleep before call to the checkStates().
> 
> Testing:
>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>  - TBD: submit mach5 tiers 1-3 to be completely safe

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

  review: use ReentrantLock.hasQueuedThread()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28734/files
  - new: https://git.openjdk.org/jdk/pull/28734/files/38ad6eec..a9c4752f

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

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

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

From sspitsyn at openjdk.org  Thu Dec 11 02:36:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Dec 2025 02:36:15 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v2]
In-Reply-To: <NHnlVqfYZ3jCk8WWouoF_4sMl27WR2YLS47Xtqf5nBA=.59cd490d-10e9-46e3-af0b-abb419884123@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <pNFFq1GurFeUuzdYqwidcUBdlRSgK0VJeRlnK60EIkI=.86846a4b-e323-4f82-8f44-c7e1c3956a28@github.com>
 <NHnlVqfYZ3jCk8WWouoF_4sMl27WR2YLS47Xtqf5nBA=.59cd490d-10e9-46e3-af0b-abb419884123@github.com>
Message-ID: <FJ4G-eofPCOavGMGTn4eHatZNWr0zy6wDrzHqjRqrzU=.1d53b2a0-fb7a-4939-8094-d5256674209a@github.com>

On Thu, 11 Dec 2025 00:54:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor correction for sleep
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 100:
> 
>> 98:         TestTask task = new ReentrantLockTestTask();
>> 99:         Thread vt = Thread.ofVirtual().name(name).start(task);
>> 100:         TestTask.sleep(50); // allow potentially needed class loading to complete
> 
> The  just sleep might be unreliable.
> 
> Would it makes sense to wait until `lock.hasQueuedThreads()` becomes true?
> 
> If 'hasQueuedThreads' doesn't work then makes to pre-load classes used by lock before running test.

Nice suggestion, thanks! It is working. Update now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28734#discussion_r2608900674

From lmesnik at openjdk.org  Thu Dec 11 03:54:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 11 Dec 2025 03:54:22 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
Message-ID: <nWTiKYBaVz7o1xBfduj8WHFlyfHFzhpdYjfPP6PGJdA=.0a1e7977-b561-4913-8103-4d26c7b91701@github.com>

On Thu, 11 Dec 2025 02:36:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use ReentrantLock.hasQueuedThread()

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 49:

> 47:     public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) {
> 48:         // wait while the thread is not ready or thread state is unexpected
> 49:         while (!threadReady || (vt.getState() != expState) || !rlock.hasQueuedThreads()) {

Small nit. 
The comment is incomplete. And code duplication is unneded. 

You can make  


task.ensureReady(vt, expState);
// Ensure that thread waiting on the rlock
while (!rlock.hasQueuedThreads()) {   
  sleep(1);
}

to reduce code duplication. 

Really,

task.ensureReady(vt, expState);

Shouldn't be needed. We can't have lock.hasQueuedThreads() == true until
we update `threadReady` and hit  `vt.getState()`. 
But I think it is fine to check all conditions.

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

PR Review: https://git.openjdk.org/jdk/pull/28734#pullrequestreview-3565479172
PR Review Comment: https://git.openjdk.org/jdk/pull/28734#discussion_r2609008674

From sspitsyn at openjdk.org  Thu Dec 11 04:50:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Dec 2025 04:50:22 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <nWTiKYBaVz7o1xBfduj8WHFlyfHFzhpdYjfPP6PGJdA=.0a1e7977-b561-4913-8103-4d26c7b91701@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
 <nWTiKYBaVz7o1xBfduj8WHFlyfHFzhpdYjfPP6PGJdA=.0a1e7977-b561-4913-8103-4d26c7b91701@github.com>
Message-ID: <HysFNcI5hPH2KqqfH2Bb25zAeNtorUy34x3BXEsKaRk=.16c4f0c5-7cfd-46e0-b45c-2e8f869f2b68@github.com>

On Thu, 11 Dec 2025 03:48:58 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: use ReentrantLock.hasQueuedThread()
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 49:
> 
>> 47:     public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) {
>> 48:         // wait while the thread is not ready or thread state is unexpected
>> 49:         while (!threadReady || (vt.getState() != expState) || !rlock.hasQueuedThreads()) {
> 
> Small nit. 
> The comment is incomplete. And code duplication is unneded. 
> 
> You can make  
> 
> 
> task.ensureReady(vt, expState);
> // Ensure that thread waiting on the rlock
> while (!rlock.hasQueuedThreads()) {   
>   sleep(1);
> }
> 
> to reduce code duplication. 
> 
> Really,
> 
> task.ensureReady(vt, expState);
> 
> Shouldn't be needed. We can't have lock.hasQueuedThreads() == true until
> we update `threadReady` and hit  `vt.getState()`. 
> But I think it is fine to check all conditions.

Thank you. I was thinking about the same but decided to go and introduce new check method.
First, the check for `rlock.hasQueuedThreads()` seems to be good enough even without `ensureReady()` call. But it is hard to be sure it is the case. Second, the check to `ensureReady()` can be returned early without waiting on the `rlock`. In such a case, we have to rely on the `rlock.hasQueuedThreads()` which does not check the target thread state. Also, the code duplication is small but it is more clean and reliable way to check the needed condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28734#discussion_r2609112411

From lmesnik at openjdk.org  Thu Dec 11 05:00:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 11 Dec 2025 05:00:25 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
Message-ID: <htlr8-gNhvTVlyERRL1ALYi9cZN0I7fz4vYnFhp4btg=.98c2631b-884e-46b5-a969-15ae34d6f29a@github.com>

On Thu, 11 Dec 2025 02:36:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use ReentrantLock.hasQueuedThread()

Looks good. Thank you for explanation.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28734#pullrequestreview-3565635342

From iklam at openjdk.org  Thu Dec 11 05:09:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 05:09:57 GMT
Subject: RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
Message-ID: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>

Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.

(JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)

**Background**

The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)


$ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
      167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig


"R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)

In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)


$ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
      313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig


Note that if an API has evolved over time, we may have several `.sig` files:


$ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
     3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
     3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
     3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig


`ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)


$ cd src/jdk.compiler/share/data/symbols
$ grep VirtualThreadSchedulerMXBean *
jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean


Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`


$ grep HotSpotAOTCacheMXBean * | wc
      0 0 0


**Proposed plan of action**

1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.

2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.

3. After JDK 26 is finalized, update the mainline:
    - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
    - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

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

Commit messages:
 - 8373464: Test JdkManagementCheckSince.java fails after JDK-8369736

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

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

From dholmes at openjdk.org  Thu Dec 11 06:04:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 06:04:22 GMT
Subject: RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Good and trivial. Thanks for fixing.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3565842150

From jbhateja at openjdk.org  Thu Dec 11 06:12:29 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 11 Dec 2025 06:12:29 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
Message-ID: <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>

On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Optimizing tail handling
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Fix failing jtreg test in CI
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
>  - Cleaning up interface as per review suggestions
>  - Some cleanups
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

> jdk/incubator/vector/Float16Vector512Tests.java



> This patch results in two of the JTREG tests failing on aarch64 machines-
> 
> ```
> jdk/incubator/vector/Float16Vector512Tests.java
> compiler/vectorapi/TestFloat16VectorOperations.java
> ```
> 
> which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test.
> 
> @jatin-bhateja Could you please add the attached fix to this patch? Thanks! [fix.patch](https://github.com/user-attachments/files/24076067/fix.patch)

Hi @Bhavana-Kilambi , Thanks for running this thorugh your setup, I am also able to reproduce it on Google AXION, your fix fills the gap in instruction selector, I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3640370652

From dholmes at openjdk.org  Thu Dec 11 06:19:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 06:19:21 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <n2ynQcHZtcqnVZ8PykHFHTAgquIgTSVpN92aAtBapV4=.f17d2583-41b3-4833-b40b-285c1f286b65@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

@plummercj  Test com/sun/jdi/RedefineCrossEvent.java is also affected by this issue

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

PR Comment: https://git.openjdk.org/jdk/pull/28730#issuecomment-3640404742

From lmesnik at openjdk.org  Thu Dec 11 06:38:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 11 Dec 2025 06:38:25 GMT
Subject: RFR: 8369150:
 serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java failed with
 COH
In-Reply-To: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <_QtxmNSHId9nv60mC3o5sIJ0ONiFiBTj61YDI59s7cs=.0e732d32-38da-4bfd-8b96-56d70ba747fe@github.com>

On Fri, 5 Dec 2025 22:23:46 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. JVMTI events however are not guaranteed to be published before the JVM exits which can occasionally cause the test to fail. Instead of failing if the events are not receive the test was modified to print an error and pass. However, the test will still fail if the method fails to compile or if the nmethod fails to relocate.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 172:

> 170:         WHITE_BOX.lockCompilation();
> 171: 
> 172:         System.out.printf("Relocated nmethod from 0x%016x to 0x%016x%n", originalNMethod.code_begin, relocatedNMethod.code_begin);

I think it is better to wait until method_unload is generated rather then don't check it in the test.
If tests times out while waiting for jvmti event we could analyze process dumps and logs trying to understand while jvmti event hasn't been posted. 
it might be sense to call WB.fullGC(), check if jvmti event posted sleep some time and repeat in the loop.

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

PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3565945862
PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2609358927

From shade at openjdk.org  Thu Dec 11 06:48:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 11 Dec 2025 06:48:23 GMT
Subject: RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <PM464vgLgd5Y5w52D6Jns7D8v8ZDYlB2imgA--jZIAk=.533bece6-a20d-4fa6-a2fa-cf95be6b8932@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3565967297

From sspitsyn at openjdk.org  Thu Dec 11 07:10:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Dec 2025 07:10:41 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
Message-ID: <qVfCFaMJGYNIUjF_XI5HuscbQiIqsT2eiydszImbJ8k=.3a644f8f-3c36-4b2b-a810-1195848c509c@github.com>

On Thu, 11 Dec 2025 02:36:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use ReentrantLock.hasQueuedThread()

Leonid, thank you for review and suggestions!

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

PR Comment: https://git.openjdk.org/jdk/pull/28734#issuecomment-3640548968

From jbhateja at openjdk.org  Thu Dec 11 07:32:58 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 11 Dec 2025 07:32:58 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v8]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <vb-vgf42wiwmQCdgQR1ouHiv3-S2gOrhG6jxL9CIj2k=.babee2e7-a37c-483f-87e5-b5b2856ecde2@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Including test changes from Bhavana Kilambi (ARM)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/44ac727d..7da5d147

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=06-07

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

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

From kevinw at openjdk.org  Thu Dec 11 07:46:43 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Dec 2025 07:46:43 GMT
Subject: RFR: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError [v2]
In-Reply-To: <pLMXdyaaWSQfoukOfQleN7mVs2ad6kWgGqTyyg2EkgE=.d00564e5-98ea-478c-840f-876f7ba280c1@github.com>
References: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
 <pLMXdyaaWSQfoukOfQleN7mVs2ad6kWgGqTyyg2EkgE=.d00564e5-98ea-478c-840f-876f7ba280c1@github.com>
Message-ID: <4Sr0T_LP7RDIsXUvMHNSrGrHf0Hizt6jnJZQfwhwuNE=.ea195255-7b68-4805-ab80-636f8bcf61e2@github.com>

On Wed, 10 Dec 2025 18:16:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test has a number of issues, described in the note below.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28747#issuecomment-3640651538

From kevinw at openjdk.org  Thu Dec 11 07:46:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Dec 2025 07:46:45 GMT
Subject: Integrated: 8370731: Tests in
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed:
 OutOfMemoryError
In-Reply-To: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
References: <eX-TX4KlgGt_YHC3MC_ADz11Tv0BUP0O5_guADFpupo=.b12b638f-01d0-4cd3-ab5b-22f319b2d0ea@github.com>
Message-ID: <14Fo-SJTkLmQcI5eqvfZa_KuHJ70Ewqnqi87bGyjfoI=.0f9a0dae-41fa-43be-8aa4-107cefe0560e@github.com>

On Wed, 10 Dec 2025 14:33:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has a number of issues, described in the note below.

This pull request has now been integrated.

Changeset: 920a99fa
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/920a99faeb6e0aee445df39cf8ddd43df18345d6
Stats:     44 lines in 5 files changed: 9 ins; 6 del; 29 mod

8370731: Tests in vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/ failed: OutOfMemoryError

Reviewed-by: sspitsyn

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

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

From kevinw at openjdk.org  Thu Dec 11 07:49:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Dec 2025 07:49:23 GMT
Subject: RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <7GQhrscxHF0C0xzLbt6r_x20JbKiKQ_0eesIiJ24Sok=.e855e891-c2d7-4c64-8bdf-7c5ea853e2d1@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3566144079

From iklam at openjdk.org  Thu Dec 11 14:36:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 14:36:34 GMT
Subject: RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
In-Reply-To: <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
 <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>
Message-ID: <u6BnHqNWnu0RXEHAtFITGFgFW7AmgdouL4wmHIvRUwA=.b8d1a2e5-7bbc-4bf7-a8d3-a3fcd2e70300@github.com>

On Thu, 11 Dec 2025 06:01:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
>> 
>> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
>> 
>> **Background**
>> 
>> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
>> 
>> 
>> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
>> 
>> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
>> 
>> 
>> Note that if an API has evolved over time, we may have several `.sig` files:
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
>> 
>> 
>> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
>> 
>> 
>> $ cd src/jdk.compiler/share/data/symbols
>> $ grep VirtualThreadSchedulerMXBean *
>> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
>> 
>> 
>> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
>> 
>> 
>> $ grep HotSpotAOTCacheMXBean * | wc
>>       0 0 0
>> 
>> 
>> **Proposed plan of action**
>> 
>> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
>> 
>> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
>> 
>> 3. After JDK 26 is finalized, update the mainline:
>>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.
>
> Good and trivial. Thanks for fixing.

Thanks @dholmes-ora @shipilev @kevinjwalls for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28760#issuecomment-3642210642

From iklam at openjdk.org  Thu Dec 11 14:36:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 14:36:36 GMT
Subject: Integrated: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <gdiiJ2nIFvD6P1ZVToMWLV9zUMLu4oYu4nwBtdBlA1c=.da64255e-e006-4000-b024-81b8c4ca60b8@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

This pull request has now been integrated.

Changeset: 2a1c676e
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a1c676e0a1a357f75ea008e8e12c7ae9340b9b1
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8373464: Test JdkManagementCheckSince.java fails after JDK-8369736

Reviewed-by: dholmes, shade, kevinw

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

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

From iklam at openjdk.org  Thu Dec 11 19:13:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 19:13:27 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache creation
Message-ID: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>

Hi all,

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

The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.

Thanks!

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

Commit messages:
 - Backport 413f852bdb4767b2a1c29431144616668888138d

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

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

From kvn at openjdk.org  Thu Dec 11 20:45:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 11 Dec 2025 20:45:49 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

Good

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28772#pullrequestreview-3569226381

From amenkov at openjdk.org  Thu Dec 11 21:17:29 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Dec 2025 21:17:29 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
Message-ID: <D_FrDg0q-STyll4-u8qTjfq4mHkxDr5LBOV5tbVVNoI=.64203371-e43c-418c-a473-7a561d8551e7@github.com>

On Thu, 11 Dec 2025 02:36:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use ReentrantLock.hasQueuedThread()

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28734#pullrequestreview-3569339045

From pchilanomate at openjdk.org  Thu Dec 11 22:13:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Dec 2025 22:13:19 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads
In-Reply-To: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>

On Wed, 10 Dec 2025 10:18:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update fixes the following problem. The function JavaThread::java_suspend has the following assert:
> 
>  bool JavaThread::java_suspend(bool register_vthread_SR) {
>    // Suspending a vthread transition disabler can cause deadlocks.
>   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");
>   . . .
> 
> This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed.
> 
> A more adequate approach is to tweak the function
> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`
> so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
> 
> Testing:
>  - In progress: mach5 tiers 1-6

Hi Serguei, some comments below, thanks.

src/hotspot/share/runtime/handshake.cpp line 524:

> 522:   assert(allow_suspend || !check_async_exception, "invalid case");
> 523: #if INCLUDE_JVMTI
> 524:   if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) {

I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation?

src/hotspot/share/runtime/javaThread.cpp line 1182:

> 1180: bool JavaThread::java_suspend(bool register_vthread_SR) {
> 1181:   // Suspending a vthread transition disabler can cause deadlocks.
> 1182:   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");

So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run?

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

PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3569493854
PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2612230146
PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2612215094

From sspitsyn at openjdk.org  Fri Dec 12 04:02:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 04:02:51 GMT
Subject: RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing [v3]
In-Reply-To: <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
 <Q33EL2b_g2HzQnynVM1lr0ow2RQ6sgQ1U8W6yX0n0gQ=.3fd3a498-5354-4a04-ae66-73886d48ec96@github.com>
Message-ID: <NbOVMgf3IY7Dziwba3SzLXgWeGlCU3I9AyKucpo-RsE=.52c4da2c-2f3c-4540-8f9d-57b102f34ae2@github.com>

On Thu, 11 Dec 2025 02:36:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes the test which is unreliable and fails intermittently from time to time.
>> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
>> The fix is to add a big enough sleep before call to the checkStates().
>> 
>> Testing:
>>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>>  - TBD: submit mach5 tiers 1-3 to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use ReentrantLock.hasQueuedThread()

Thank you for review, Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/28734#issuecomment-3644806138

From sspitsyn at openjdk.org  Fri Dec 12 04:07:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 04:07:06 GMT
Subject: Integrated: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
References: <RvqN7cAmJa4DpA_rX9tSDqurStAVSeP4iYXJQhu6hyc=.3dae9128-ee61-405a-9209-1812d5b6a087@github.com>
Message-ID: <b6OYBB13hohOxATFJQCYcXWPEQsqCZMMnjrXfmIYJqM=.64b1e0ce-f6e5-4a23-b599-e297729136e4@github.com>

On Wed, 10 Dec 2025 06:00:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes the test which is unreliable and fails intermittently from time to time.
> The test was failing in the method `checkReentrantLock()` when comparing the expected state with result from `vt.getState()`. The issue is that the call to `ThreadListStackTracesTest.reentrantLock.lock()` in a `ReentrantLockTestTask` can reach waiting state on some class loading but not on the ReentrantLock. Please see the first comment for test sources details.
> The fix is to add a big enough sleep before call to the checkStates().
> 
> Testing:
>  - submitted about thousands of mach5 runs of the `ThreadListStackTracesTest` test runs before and after the fix
>  - TBD: submit mach5 tiers 1-3 to be completely safe

This pull request has now been integrated.

Changeset: c46bed72
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8371502: serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java failing

Reviewed-by: lmesnik, amenkov

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

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

From jsikstro at openjdk.org  Fri Dec 12 09:30:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 09:30:51 GMT
Subject: [jdk26] RFR: 8373022: serviceability/sa/ClhsdbScanOops.java
 assumes no GC should occur
In-Reply-To: <_v8LeEbI0syTU06pMh8biGOKNhWYWptsJBNLAGKG414=.434b969b-0c51-4141-95e0-00aedbd35c39@github.com>
References: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
 <_v8LeEbI0syTU06pMh8biGOKNhWYWptsJBNLAGKG414=.434b969b-0c51-4141-95e0-00aedbd35c39@github.com>
Message-ID: <2ZjEk4L2pvHHUs6SAXlElWNlJM3FEhDA0F3jBRt4MMM=.b71c4d73-8ad0-44e3-a846-c27eb12e405c@github.com>

On Wed, 10 Dec 2025 09:52:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [786833cd](https://github.com/openjdk/jdk/commit/786833cd1bf8eda1cef25da392a055f4eb371abf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Joel Sikstr?m on 9 Dec 2025 and was reviewed by Chris Plummer, Stefan Karlsson, Albert Mingkun Yang and Thomas Schatzl.
>> 
>> Apart from the "clean" backport commit, I've changed the issue number for MethodInvokeWithTraceOnTest.java to [JDK-8373102](https://bugs.openjdk.org/browse/JDK-8373102), since the problem list is currently associated with this issue.
>> 
>> Thanks!
>
> Marked as reviewed by stefank (Reviewer).

Thank you for the reviews @stefank @kevinjwalls!

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

PR Comment: https://git.openjdk.org/jdk/pull/28737#issuecomment-3645660688

From jsikstro at openjdk.org  Fri Dec 12 09:34:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 09:34:05 GMT
Subject: [jdk26] Integrated: 8373022: serviceability/sa/ClhsdbScanOops.java
 assumes no GC should occur
In-Reply-To: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
References: <giLkTIz_Bk8rC9H1OtZs9ifZHP4Ulft89RMnQB7BCWw=.d5a28d10-feab-491f-b39f-7df61b2b4370@github.com>
Message-ID: <UiYeGTf9izUC_Ot-SzJDTm0Iw1mGMdbVSpfltwvhOp0=.d74e5586-459d-40c0-976e-c517981e2199@github.com>

On Wed, 10 Dec 2025 09:31:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [786833cd](https://github.com/openjdk/jdk/commit/786833cd1bf8eda1cef25da392a055f4eb371abf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Joel Sikstr?m on 9 Dec 2025 and was reviewed by Chris Plummer, Stefan Karlsson, Albert Mingkun Yang and Thomas Schatzl.
> 
> Apart from the "clean" backport commit, I've changed the issue number for MethodInvokeWithTraceOnTest.java to [JDK-8373102](https://bugs.openjdk.org/browse/JDK-8373102), since the problem list is currently associated with this issue.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 85eb6b75
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85eb6b752eba5216f9a6db2d29d45d866699d5b5
Stats:     8 lines in 3 files changed: 3 ins; 3 del; 2 mod

8373022: serviceability/sa/ClhsdbScanOops.java assumes no GC should occur

Reviewed-by: stefank, kevinw
Backport-of: 786833cd1bf8eda1cef25da392a055f4eb371abf

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

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

From duke at openjdk.org  Fri Dec 12 09:43:31 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Fri, 12 Dec 2025 09:43:31 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>

On Fri, 18 Jul 2025 13:13:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:

> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
> 1069: 
> 1070:     if (UseAdaptiveSizePolicy) {

I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2613566233

From sspitsyn at openjdk.org  Fri Dec 12 10:56:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 10:56:18 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads
In-Reply-To: <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
Message-ID: <-Of70ssdlYqY5Ye1S7vxRo6j5w-NmxBHGpXy0wPjKu4=.ee93fbde-3e11-4644-a888-d74f845bcb7f@github.com>

On Thu, 11 Dec 2025 22:03:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This update fixes the following problem. The function JavaThread::java_suspend has the following assert:
>> 
>>  bool JavaThread::java_suspend(bool register_vthread_SR) {
>>    // Suspending a vthread transition disabler can cause deadlocks.
>>   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");
>>   . . .
>> 
>> This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed.
>> 
>> A more adequate approach is to tweak the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`
>> so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> src/hotspot/share/runtime/javaThread.cpp line 1182:
> 
>> 1180: bool JavaThread::java_suspend(bool register_vthread_SR) {
>> 1181:   // Suspending a vthread transition disabler can cause deadlocks.
>> 1182:   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");
> 
> So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run?

You are asking right question, thanks!
I've found and fixed the issue caused this and also restored the assert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2613792839

From sspitsyn at openjdk.org  Fri Dec 12 11:03:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 11:03:03 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v2]
In-Reply-To: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <BiY5ArIAyE4Go3AaznYgbmfxLLvgB7mrp4krq9trMp8=.9b99cfec-6c5e-4261-b405-d4847065f696@github.com>

> This update fixes the following problem. The function JavaThread::java_suspend has the following assert:
> 
>  bool JavaThread::java_suspend(bool register_vthread_SR) {
>    // Suspending a vthread transition disabler can cause deadlocks.
>   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");
>   . . .
> 
> This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed.
> 
> A more adequate approach is to tweak the function
> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`
> so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
> 
> Testing:
>  - In progress: mach5 tiers 1-6

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

  review: restored the assert and fixed the issue caused it to fire

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28740/files
  - new: https://git.openjdk.org/jdk/pull/28740/files/8c25f690..b51267f3

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

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

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

From sspitsyn at openjdk.org  Fri Dec 12 11:46:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 11:46:57 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v2]
In-Reply-To: <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
Message-ID: <MskmOnIIvP6LK97KGsZEJ4E63CIZ33Y87OO8Az9NBe4=.c863ebe3-ae5f-4d65-b481-6d1d4d6c10d8@github.com>

On Thu, 11 Dec 2025 22:07:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: restored the assert and fixed the issue caused it to fire
>
> src/hotspot/share/runtime/handshake.cpp line 524:
> 
>> 522:   assert(allow_suspend || !check_async_exception, "invalid case");
>> 523: #if INCLUDE_JVMTI
>> 524:   if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) {
> 
> I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation?

Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes.
As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2613932869

From sspitsyn at openjdk.org  Fri Dec 12 11:53:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 11:53:58 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v2]
In-Reply-To: <ou3LP7hbkrbn2ZJ3lBLtYJ1eSbqW8tWbzAmeN3r00p0=.6960e947-a426-4b2b-90c3-b50451abc97f@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <ou3LP7hbkrbn2ZJ3lBLtYJ1eSbqW8tWbzAmeN3r00p0=.6960e947-a426-4b2b-90c3-b50451abc97f@github.com>
Message-ID: <QK59Z3opHcN9JCCbp_64oke4-bLzcJecPtijkF4Ug6s=.bb733dbf-b6ea-4499-afb0-50536d027cfe@github.com>

On Thu, 11 Dec 2025 07:40:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> However, I think the it makes a sense to add regression test that tries to suspend thread while it processing event callback.

Right question, thanks. This issue came from testing of the PR https://github.com/openjdk/jdk/pull/28407 .
The issue appeared on the updated test:  `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest`.
Initially, I wanted to move the test update to this PR but encountered one more issue which needs to be addressed separately. So, I gave up on moving the test update.

> Can you please show where mounting/unmounting is disabled for jvmti events. i was unable to fines this place.

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

PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3646170897

From sspitsyn at openjdk.org  Fri Dec 12 12:47:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 12:47:20 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
 <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>
 <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>
Message-ID: <ui6AkWWErrmV1ww7BUOluz5WijdgSEMjlu0eaKYlkjc=.afa606c6-17f2-4898-8561-a74533d58df2@github.com>

On Fri, 5 Dec 2025 09:42:51 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module.
>> We got the following concerns:
>>  - Do we really need 3x implementations of the MacOS `tempdir` finder function?
>>  - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`?
>> New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
>> My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
>> Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this.
>
> Hi @sspitsyn ,
> 
> Thank you for looking at this patch!
> 
>> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions?
> 
> The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root.
> 
>> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
> 
> The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory.
> 
>> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct?
> 
> I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux).
> 
>> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
> 
> Yes and this is what this patch was intended for.
> 
>>     * Do we really need 3x implementations of the MacOS `tempdir` finder function?
> 
> It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to.
> 
>>     * Do we really need a modular dependency f...

@sercher  I have a plan to submit mach5 tiers 1-6 to be completely safe from regressions.
Will approve this PR if the results are good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3646340957

From iklam at openjdk.org  Fri Dec 12 14:33:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:33:14 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
 <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
Message-ID: <_kA4bTDICP0GPkKHWYobWxOKJ4XXQDkOonFi7Zr_GlY=.742b2034-8086-48d0-803b-874428cd8214@github.com>

On Thu, 11 Dec 2025 20:43:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
>> 
>> Thanks!
>
> Good

Thanks @vnkozlov for the review
Passed tiers 1 - 4 and builds-tier-5

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

PR Comment: https://git.openjdk.org/jdk/pull/28772#issuecomment-3646707792

From iklam at openjdk.org  Fri Dec 12 14:36:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:36:42 GMT
Subject: [jdk26] Integrated: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <qFwM_ybl67eTZMO_XCyFNisH7fP40fWYjNg3IABJVF8=.93f68a4b-45cb-403a-9184-be8c50c36efb@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d9bc8221
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9bc82216842bf521ccb7c451b4b411adb0cf3cc
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: kvn
Backport-of: 413f852bdb4767b2a1c29431144616668888138d

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

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

From iklam at openjdk.org  Fri Dec 12 15:03:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 15:03:01 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
Message-ID: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>

The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.

This PR removes this field and simplified the creation of `DCmdFactory` objects.

The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.

Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

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

Commit messages:
 - Added comments about Java API
 - 8373441: Remove DCmdFactory::_enabled

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

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

From jsjolen at openjdk.org  Fri Dec 12 15:54:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Dec 2025 15:54:00 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <QYbz0RunslxVNZl_SNODduk9j5kl7LXpfiXiCUu9A9w=.4f7bdb43-9f66-4b9a-aa66-b6c7340cc7af@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

Fine by me, thanks.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3572462286

From kevinw at openjdk.org  Fri Dec 12 16:55:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 12 Dec 2025 16:55:50 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

The Java API has "enabled" handled in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java
(and read in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java)

In the public API docs we do specify a Descriptor for diagnostic commands:

https://docs.oracle.com/en/java/javase/25/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html
dcmd.enabled	boolean	True if the diagnostic command is enabled, false otherwise

dcmd.enabled is already not very meaningful as it's always true, but if it becomes truly meaningless, it needs thought on whether it stays, maybe with a comment that it is always true, or can be removed.

The Java api deals with remote connections, so interactions between JDK versions need considering.
If dcmd.enabled is not found, if a client app ever checks this Descriptor, does the app think it's not enabled?

Maybe it stays in the Descriptor for compatibility reasons, but can be removed from DiagnosticCommandInfo.

This could be a follow up issue if we aren't doing it now.

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

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3572764279

From pchilanomate at openjdk.org  Fri Dec 12 17:05:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 12 Dec 2025 17:05:02 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v2]
In-Reply-To: <MskmOnIIvP6LK97KGsZEJ4E63CIZ33Y87OO8Az9NBe4=.c863ebe3-ae5f-4d65-b481-6d1d4d6c10d8@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
 <MskmOnIIvP6LK97KGsZEJ4E63CIZ33Y87OO8Az9NBe4=.c863ebe3-ae5f-4d65-b481-6d1d4d6c10d8@github.com>
Message-ID: <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com>

On Fri, 12 Dec 2025 11:44:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 524:
>> 
>>> 522:   assert(allow_suspend || !check_async_exception, "invalid case");
>>> 523: #if INCLUDE_JVMTI
>>> 524:   if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) {
>> 
>> I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation?
>
> Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes.
> As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario.

Right, I was just curious whether you ran into this issue or only found it by code inspection. But I'm guessing you found disablers processing `ThreadSelfSuspensionHandshakeClosure` handshakes because of the other issue in `enable_transition_for_all()`, and that accidentally led you to consider this other potential case where a thread is suspended before entering a `MountUnmountDisabler` scope but processes the async handshake inside it? Thanks for updating the PR description.

>> src/hotspot/share/runtime/javaThread.cpp line 1182:
>> 
>>> 1180: bool JavaThread::java_suspend(bool register_vthread_SR) {
>>> 1181:   // Suspending a vthread transition disabler can cause deadlocks.
>>> 1182:   assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers");
>> 
>> So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run?
>
> You are asking right question, thanks!
> I've found and fixed the issue caused this and also restored the assert.
> I will also need to update the PR description to reflect this change.

Thanks! Now it makes sense why we were hitting this assert. Since that was introduced in 8364343 I think we should separate that fix and backport it to 26.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2614963770
PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2614961974

From lmesnik at openjdk.org  Fri Dec 12 21:01:51 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 Dec 2025 21:01:51 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <symTmyWTFRRQFYzNxvphU-HMdNOi7SgYPpAAfqZqcMQ=.38663bc7-a8d9-4c4f-9579-d3bae6d2e1a0@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28730#pullrequestreview-3573585793

From sspitsyn at openjdk.org  Fri Dec 12 21:10:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 21:10:04 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v10]
In-Reply-To: <JPGc7Ta6ynI22ic12JkKS4Iw5lYeiwvuAkBWMFmdqTE=.de39a3b3-aef5-4a8a-a5bb-7da278b059c8@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <JPGc7Ta6ynI22ic12JkKS4Iw5lYeiwvuAkBWMFmdqTE=.de39a3b3-aef5-4a8a-a5bb-7da278b059c8@github.com>
Message-ID: <gTiJOP9GNIyc_OpyjOITZzo6rl-zkFmGSdDZqiRWHnE=.5ed202cc-aa13-472e-b077-6562dbf1b843@github.com>

On Mon, 8 Dec 2025 21:34:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright header

The fix looks good - approved. Thank you for your patience!
Larry is also okay with your fix but does not have status yet to formally approve.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3573605043

From sspitsyn at openjdk.org  Fri Dec 12 21:13:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Dec 2025 21:13:55 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v2]
In-Reply-To: <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <GeDGq3mtZoiFxNjIBSfLbMcxLJZSn1uEL9IQrjXUxP4=.07dd95b4-1d7b-4c08-8b4d-92b7b5918da3@github.com>
 <MskmOnIIvP6LK97KGsZEJ4E63CIZ33Y87OO8Az9NBe4=.c863ebe3-ae5f-4d65-b481-6d1d4d6c10d8@github.com>
 <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com>
Message-ID: <UUjLN26d3NLJHOykumuyBp-XHlLZhzy7XfvEUK3gg4U=.a7282df7-3ca3-47e2-b1b3-22ffa1023d90@github.com>

On Fri, 12 Dec 2025 17:02:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes.
>> As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario.
>
> Right, I was just curious whether you ran into this issue or only found it by code inspection. But I'm guessing you found disablers processing `ThreadSelfSuspensionHandshakeClosure` handshakes because of the other issue in `enable_transition_for_all()`, and that accidentally led you to consider this other potential case where a thread is suspended before entering a `MountUnmountDisabler` scope but processes the async handshake inside it? Thanks for updating the PR description.

This is right, thanks!

>> You are asking right question, thanks!
>> I've found and fixed the issue caused this and also restored the assert.
>> I will also need to update the PR description to reflect this change.
>
> Thanks! Now it makes sense why we were hitting this assert. Since that was introduced in 8364343 I think we should separate that fix and backport it to 26.

Thanks. Okay, will do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2615590699
PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2615586743

From jnorlinder at openjdk.org  Fri Dec 12 21:40:04 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 12 Dec 2025 21:40:04 GMT
Subject: RFR: 8373625: CPUTimeCounters creates a total counter for unsupported
 GCs
Message-ID: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>

`CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get


[7.907s][info][cpu] === CPU time Statistics =============================================================
[7.907s][info][cpu]                                                                             CPUs
[7.907s][info][cpu]                                                                s       %  utilized
[7.907s][info][cpu]    Process
[7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
[7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
[7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
[7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
[7.907s][info][cpu] =====================================================================================


But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

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

Commit messages:
 - Only create sun.threads.total_gc_cpu_time if we run a supported GC

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

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

From iklam at openjdk.org  Fri Dec 12 23:37:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:20 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @kevinjwalls comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28794/files
  - new: https://git.openjdk.org/jdk/pull/28794/files/8a047713..98176aa7

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

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

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

From iklam at openjdk.org  Fri Dec 12 23:37:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:22 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
Message-ID: <5L7tLI0Xi70wDBou7BLE4TNtcUQRdlKRPUEjsM_77mE=.823865fb-28f1-4879-8e05-a811b24cf590@github.com>

On Fri, 12 Dec 2025 16:53:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The Java API has "enabled" handled in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java (and read in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java)
> 
> In the public API docs we do specify a Descriptor for diagnostic commands:
> 
> https://docs.oracle.com/en/java/javase/25/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html dcmd.enabled boolean True if the diagnostic command is enabled, false otherwise
> 
> dcmd.enabled is already not very meaningful as it's always true, but if it becomes truly meaningless, it needs thought on whether it stays, maybe with a comment that it is always true, or can be removed.
> 
> The Java api deals with remote connections, so interactions between JDK versions need considering. If dcmd.enabled is not found, if a client app ever checks this Descriptor, does the app think it's not enabled?
> 
> Maybe it stays in the Descriptor for compatibility reasons, but can be removed from DiagnosticCommandInfo.
> 
> This could be a follow up issue if we aren't doing it now.

For compatibility reasons, I don't want to touch the Java APIs in this PR. I updated the comments in DiagnosticCommandMBean.java to say


 *     <th scope="row">dcmd.enabled</th><td>boolean</td>
 *     <td>This field is always true -- diagnostic commands cannot be disabled.</td>

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3648510642

From ayang at openjdk.org  Sat Dec 13 02:07:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 13 Dec 2025 02:07:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
Message-ID: <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>

On Fri, 12 Dec 2025 09:37:48 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
>> 
>>  - merge
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:
> 
>> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
>> 1069: 
>> 1070:     if (UseAdaptiveSizePolicy) {
> 
> I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

@SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2615984879

From syan at openjdk.org  Mon Dec 15 02:35:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 02:35:51 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <TX35KNFqfj6MHeCGxnjbmtjV75kWHCRNHxen3jZVyks=.5f8100f2-c126-4972-84a9-0bcd4f3a915a@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Looking for 2rd reviewer, since this PR touch files in hotspot directory?

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

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3652648703

From dholmes at openjdk.org  Mon Dec 15 04:21:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 04:21:27 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
Message-ID: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>

As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.

The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.

There is no regression test as this has only been seen in long running stress tests.

Testing:
   -tiers 1-6

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

Commit messages:
 - 8369515

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

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

From dholmes at openjdk.org  Mon Dec 15 05:38:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 05:38:52 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

I'm unclear what you mean by some of the tests not working - are you saying those tests did not check the value of RETAIN_IMAGE_AFTER_TEST? Or that they never had it passed in - in which case why not? Where does it come from.

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255:

> 253:             if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) {
> 254:                 execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag);
> 255:             }

Pre-existing but indent is too big

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

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576429184
PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617997460

From dholmes at openjdk.org  Mon Dec 15 05:38:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 05:38:53 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>
Message-ID: <XdAk8Ixwtsu-3Wz28_QiKl-F_3pSHQcjGY325wFRJTk=.2e296ca8-8dcd-4366-8d3e-c2c9aab43569@github.com>

On Mon, 15 Dec 2025 05:28:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
>> 
>> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
>> 
>> Change has been verified locally on linux-x64 by run the all touched tests.
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255:
> 
>> 253:             if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) {
>> 254:                 execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag);
>> 255:             }
> 
> Pre-existing but indent is too big

You also need to document the fact the property is used to make this a no-op.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617999664

From dholmes at openjdk.org  Mon Dec 15 06:13:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:13:55 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3653521831

From syan at openjdk.org  Mon Dec 15 06:15:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 06:15:58 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>
Message-ID: <RUE5pAEjN_gOue1u5UamrPNg5ERSoVOD841O-ch6ukU=.269cce4b-3dd7-4737-80bc-71a68ca7cc2b@github.com>

On Mon, 15 Dec 2025 05:35:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> RETAIN_IMAGE_AFTER_TEST

Some tests did not check the value of the RETAIN_IMAGE_AFTER_TEST variable, causing the docker image to be deleted at the end of the test run even if the -DRETAIN_IMAGE_AFTER_TEST=true option was used when running those tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3653534316

From syan at openjdk.org  Mon Dec 15 06:18:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 06:18:35 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v2]
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <ov2Ga8sURD8t82l63XbSsHlBMAOCPUbFjctUK3ZsKqY=.b58e63bc-c07f-4460-a990-601fd3a798d9@github.com>

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

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

  Remove extra ident

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28208/files
  - new: https://git.openjdk.org/jdk/pull/28208/files/75356d0e..5e39c8f3

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

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

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

From syan at openjdk.org  Mon Dec 15 06:25:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 06:25:43 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v3]
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

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

 - Merge branch 'openjdk:master' into jbs8371503
 - Remove extra ident
 - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28208/files
  - new: https://git.openjdk.org/jdk/pull/28208/files/5e39c8f3..0bfbe8ae

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

  Stats: 301873 lines in 2852 files changed: 201864 ins; 58740 del; 41269 mod
  Patch: https://git.openjdk.org/jdk/pull/28208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208

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

From syan at openjdk.org  Mon Dec 15 06:31:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 06:31:52 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v3]
In-Reply-To: <XdAk8Ixwtsu-3Wz28_QiKl-F_3pSHQcjGY325wFRJTk=.2e296ca8-8dcd-4366-8d3e-c2c9aab43569@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <vVnIyk5ARb9YWxmXRQQZeeY77mGRplF7IHpBrM1mFpU=.4568cda1-b9a0-4ce1-bc1e-7ba7bca24a83@github.com>
 <XdAk8Ixwtsu-3Wz28_QiKl-F_3pSHQcjGY325wFRJTk=.2e296ca8-8dcd-4366-8d3e-c2c9aab43569@github.com>
Message-ID: <_TW1mSrJRHz9EYzpiDbjXIPk4IexJ1bX53I8U0s_Ec8=.63403b1b-e590-428f-abb7-8e20861f307d@github.com>

On Mon, 15 Dec 2025 05:29:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255:
>> 
>>> 253:             if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) {
>>> 254:                 execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag);
>>> 255:             }
>> 
>> Pre-existing but indent is too big
>
> You also need to document the fact the property is used to make this a no-op.

> Pre-existing but indent is too big

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2618130670

From dholmes at openjdk.org  Mon Dec 15 06:47:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:47:59 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v3]
In-Reply-To: <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>
Message-ID: <6vq4NQJDnsQ_06T_1Tqfx8MmiNv2dAWYIet1OgDT1X8=.5789459a-ec8b-4bb0-8ab1-76120b28becd@github.com>

On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
>> 
>> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
>> 
>> Change has been verified locally on linux-x64 by run the all touched tests.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8371503
>  - Remove extra ident
>  - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Thanks - now it makes sense to me.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576654982

From lmesnik at openjdk.org  Mon Dec 15 08:00:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 15 Dec 2025 08:00:58 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v3]
In-Reply-To: <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>
Message-ID: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com>

On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
>> 
>> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
>> 
>> Change has been verified locally on linux-x64 by run the all touched tests.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8371503
>  - Remove extra ident
>  - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576911752

From rrich at openjdk.org  Mon Dec 15 10:26:08 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 15 Dec 2025 10:26:08 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <wMkcwC58TwDiGv1yMKfq3ZTBLj4HmU7VHce5xAbPpyU=.f6a5adc3-88cc-4279-bff6-d2aef46138f7@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

Thanks for providing a fix for the issue David.
I've scheduled some local testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3654877794

From schernyshev at openjdk.org  Mon Dec 15 11:04:42 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 15 Dec 2025 11:04:42 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v8]
In-Reply-To: <ui6AkWWErrmV1ww7BUOluz5WijdgSEMjlu0eaKYlkjc=.afa606c6-17f2-4898-8561-a74533d58df2@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com>
 <O4N_-q08VMIQ0lWgRfTQOv7KDn7Siss9I2Eg9URZ_8c=.cf97d2a5-f453-4071-853a-a19cfb49d7e9@github.com>
 <KJHL4XTIPBQ_XiM9hRiWie-8DWMvIRlnrv-RXsyEjQQ=.47bb41da-744b-446d-b283-649222e9bd96@github.com>
 <ui6AkWWErrmV1ww7BUOluz5WijdgSEMjlu0eaKYlkjc=.afa606c6-17f2-4898-8561-a74533d58df2@github.com>
Message-ID: <1rGGt2ZaCUWE8YxQcsc_ubtHebJCzgqZochwtBQBLMI=.70ed4908-7cbb-451d-97dc-c0a74e09835e@github.com>

On Fri, 12 Dec 2025 12:44:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hi @sspitsyn ,
>> 
>> Thank you for looking at this patch!
>> 
>>> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions?
>> 
>> The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root.
>> 
>>> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module.
>> 
>> The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory.
>> 
>>> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)`  is not currently used for `jvmstat` implementation. Is it correct?
>> 
>> I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux).
>> 
>>> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS?
>> 
>> Yes and this is what this patch was intended for.
>> 
>>>     * Do we really need 3x implementations of the MacOS `tempdir` finder function?
>> 
>> It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to.
>> 
>>>   ...
>
> @sercher  I have a plan to submit mach5 tiers 1-6 to be completely safe from regressions.
> Will approve this PR if the results are good.

Thank you @sspitsyn and @larry-cable for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3655030577

From duke at openjdk.org  Mon Dec 15 11:07:48 2025
From: duke at openjdk.org (duke)
Date: Mon, 15 Dec 2025 11:07:48 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v10]
In-Reply-To: <JPGc7Ta6ynI22ic12JkKS4Iw5lYeiwvuAkBWMFmdqTE=.de39a3b3-aef5-4a8a-a5bb-7da278b059c8@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <JPGc7Ta6ynI22ic12JkKS4Iw5lYeiwvuAkBWMFmdqTE=.de39a3b3-aef5-4a8a-a5bb-7da278b059c8@github.com>
Message-ID: <IdeVGsBIuFCEAFsjHNWmvqwc1CcYEu7RvbqkdspWHlI=.d9a3b827-d52b-4893-91db-f0bb551c87d1@github.com>

On Mon, 8 Dec 2025 21:34:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright header

@sercher 
Your change (at version c318ac87dc28b1812d2fcd2873d70fe59fd13ab3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3655040763

From duke at openjdk.org  Mon Dec 15 12:54:07 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Mon, 15 Dec 2025 12:54:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
Message-ID: <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>

On Sat, 13 Dec 2025 02:04:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:
>> 
>>> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
>>> 1069: 
>>> 1070:     if (UseAdaptiveSizePolicy) {
>> 
>> I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk
>
> @SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)

@albertnetymk Sure.  I will give detailed description here.

GC?PS MarkSweep?PS Scavenge

JVM configuraton:  
-Xmx2g 
-Xms256M 
-XX:MetaspaceSize=256m 
-XX:MaxMetaspaceSize=256m 
-XX:+PrintGCDateStamps 
-XX:+PrintGCDetails 
-XX:-UseAdaptiveSizePolicy 
-XX:+PrintAdaptiveSizePolicy 
-XX:+HeapDumpBeforeFullGC 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=export/Logs/ 
-Xloggc:/export/Logs/gclogs.log 

JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.

Problem Description: 
When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.

Check List:
1. Container has enough place for heap expansion
2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion

GC log sample:
// Full GC Starting
[PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174276K->174980K(175104K)] 239812K->174980K(251392K), [Metaspace: 110351K->110351K(1148928K)], 0.3664816 secs] [Times: user=1.21 sys=0.00, real=0.37 secs]
// Full GC Running
2025-12-10T14:12:52.408+0800: 78.350: [Heap Dump (before full gc): , 0.0000535 secs]2025-12-10T14:12:52.409+0800: 78.350: [Full GC (Ergonomics) [PSYoungGen: 65536K->64255K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240429K->239149K(251392K), [Metaspace: 148330K->148330K(1183744K)], 0.2442300 secs] [Times: user=0.68 sys=0.00, real=0.25 secs] 
2025-12-10T14:12:52.656+0800: 78.598: [Heap Dump (before full gc): , 0.0000711 secs]2025-12-10T14:12:52.657+0800: 78.598: [Full GC (Ergonomics) [PSYoungGen: 65536K->64333K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240429K->239227K(251392K), [Metaspace: 148379K->148379K(1183744K)], 0.2102640 secs] [Times: user=0.53 sys=0.02, real=0.21 secs] 
2025-12-10T14:12:52.871+0800: 78.813: [Heap Dump (before full gc): , 0.0000622 secs]2025-12-10T14:12:52.872+0800: 78.813: [Full GC (Ergonomics) [PSYoungGen: 65534K->64252K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240428K->239146K(251392K), [Metaspace: 148488K->148488K(1183744K)], 0.2125166 secs] [Times: user=0.54 sys=0.00, real=0.22 secs]  
// Full GC Ending
2025-12-10T14:32:47.691+0800: 1273.632: [Heap Dump (before full gc): , 0.0000943 secs]2025-12-10T14:32:47.691+0800: 1273.633: [Full GC (Ergonomics) [PSYoungGen: 65536K->24273K(76288K)] [ParOldGen: 174627K->174626K(175104K)] 240163K->198899K(251392K), [Metaspace: 152567K->152567K(1187840K)], 0.3627505 secs] [Times: user=1.12 sys=0.00, real=0.37 secs] 
2025-12-10T14:35:18.172+0800: 1424.113: [Heap Dump (before full gc): , 0.0001014 secs]2025-12-10T14:35:18.172+0800: 1424.114: [Full GC (Ergonomics) [PSYoungGen: 65536K->9012K(76288K)] [ParOldGen: 174626K->174852K(175104K)] 240162K->183865K(251392K), [Metaspace: 152611K->152611K(1187840K)], 0.2574051 secs] [Times: user=0.63 sys=0.00, real=0.26 secs] 
2025-12-10T14:38:49.044+0800: 1634.986: [Heap Dump (before full gc): , 0.0001049 secs]2025-12-10T14:38:49.045+0800: 1634.987: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174852K->133113K(175104K)] 240388K->133113K(251392K), [Metaspace: 152680K->152680K(1187840K)], 0.3655573 secs] [Times: user=1.01 sys=0.00, real=0.36 secs] 
2025-12-10T14:42:49.842+0800: 1875.784: [GC (Allocation Failure) AdaptiveSizePolicy::update_averages:  survived: 1671680  promoted: 0  overflow: false

If you need other details just let me know, thx!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2619293977

From syan at openjdk.org  Mon Dec 15 14:21:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 14:21:44 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
 [v3]
In-Reply-To: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
 <mOLnyqlL_fqPpM_SXKqCDp52rrWPQDL4LO8DJGlFGZo=.51d2f9d9-280b-43fe-8586-68115f0bf510@github.com>
 <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com>
Message-ID: <R2OrijP2Y-ozyADPHJRqv-lEkju_Cf5hKD_9ruSxBeg=.4c13eaca-c600-40ce-9510-af622b0dfca7@github.com>

On Mon, 15 Dec 2025 07:58:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jbs8371503
>>  - Remove extra ident
>>  - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks for the reviews @lmesnik @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3655876260

From syan at openjdk.org  Mon Dec 15 14:21:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 14:21:46 GMT
Subject: Integrated: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <dL23w7O3QcKRA3tDIfuXEb7LsKVOeexK4Pk0Kk36T34=.4d6ad94e-be00-470e-b2f4-dd3cbd070b51@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

This pull request has now been integrated.

Changeset: 34f24131
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c
Stats:     32 lines in 11 files changed: 2 ins; 20 del; 10 mod

8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Reviewed-by: lmesnik, dholmes

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

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

From syan at openjdk.org  Mon Dec 15 14:39:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 15 Dec 2025 14:39:51 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests
Message-ID: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>

Hi all,

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

The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.

Thanks!

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

Commit messages:
 - Backport 34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c

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

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

From rrich at openjdk.org  Mon Dec 15 15:54:29 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 15 Dec 2025 15:54:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <HNIuDe5WE7Q2TcLEypSmjKG0aEH2H3GtnLSCGYWdzlQ=.3f0582a5-5184-4416-8d0e-c61139541c33@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

@dholmes-ora I do think that also _entering_ a critical region is problematic if it is nested.
I'm currently testing with https://github.com/reinrich/jdk/commit/d7ce2ccb2150c92929b8d9140b4709833d188474 where a thread doesn't suspend for EscapeBarriers while in a critical region.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3656372702

From cjplummer at openjdk.org  Mon Dec 15 17:05:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Dec 2025 17:05:09 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <n2ynQcHZtcqnVZ8PykHFHTAgquIgTSVpN92aAtBapV4=.f17d2583-41b3-4833-b40b-285c1f286b65@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
 <n2ynQcHZtcqnVZ8PykHFHTAgquIgTSVpN92aAtBapV4=.f17d2583-41b3-4833-b40b-285c1f286b65@github.com>
Message-ID: <riKsv3txs26T7L-vjrHR96fCYEdDT5QE-xDKm4I-h_4=.30f48588-c7d7-44f7-b277-ff75eee777ab@github.com>

On Thu, 11 Dec 2025 06:17:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @plummercj Test com/sun/jdi/RedefineCrossEvent.java is also affected by this issue

Yes. That's because RedefineCrossEvent runs AfterThreadDeathEvent.

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

PR Comment: https://git.openjdk.org/jdk/pull/28730#issuecomment-3656701693

From cjplummer at openjdk.org  Mon Dec 15 19:51:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Dec 2025 19:51:06 GMT
Subject: RFR: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <KtDXqBCKNXGBG2QUJYDolJaItKF6pIFFOTH38CG6zdg=.44d64843-45fe-4c0c-ba35-efc4c19dca82@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

Thank you fro the reviews Serguei, Alex, Kevin, and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/28730#issuecomment-3657324687

From cjplummer at openjdk.org  Mon Dec 15 19:54:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Dec 2025 19:54:16 GMT
Subject: Integrated: 8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed
 with unexpected ObjectCollectedException
In-Reply-To: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
References: <5OBvj_AxTIE-Lr8yJf-S8TrGK3p8d9rk3SOWoTUxCxA=.1d73a77b-9698-4b92-a7d7-1af3c9d9df24@github.com>
Message-ID: <YINFw1je_vbLxgCIgc2oMztOKIuYyOFJPG9ty3H26R0=.46262fa6-85fc-4edc-804f-d65812099d8d@github.com>

On Tue, 9 Dec 2025 22:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The thread object for the main thread is getting unexpectedly collected. This results in an ObjectCollectedException during the test's handling of the ThreadDeath event. It tries enabling a SingleStepRequest on the thread, but the thread an already been collected by this time since the ThreadDeath event is using the SUSPEND_NONE policy, allowing the thread to exit.
> 
> This fix is to simply call ObjectReference.disableCollection() on the main thread. It will never be collected after this point. No need to ever call enableCollection(), because the debuggee is just going to exit anyway.
> 
> Testing
> - Tier1 CI
> - Tier5 CI pruned to just run svc tests

This pull request has now been integrated.

Changeset: 45ee89c4
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45ee89c4c8e3d8bb418b8578fb361e7dc1c12be5
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8373297: Test com/sun/jdi/AfterThreadDeathTest.java failed with unexpected ObjectCollectedException

Reviewed-by: kevinw, sspitsyn, amenkov, lmesnik

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

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

From schernyshev at openjdk.org  Mon Dec 15 20:22:51 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 15 Dec 2025 20:22:51 GMT
Subject: Integrated: 8319589: Attach from root to a user java process not
 supported in Mac
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <wpZd8PWyj7VoXSz7q7p5x2fIyCDe76lO0rYe6kDwQX8=.78352156-864f-4b5e-8428-a0fd18508905@github.com>

On Mon, 16 Jun 2025 09:46:11 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The...

This pull request has now been integrated.

Changeset: f52d4992
Author:    Sergey Chernyshev <schernyshev at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f52d49925f9c60814a0a34720d7443e748b35c25
Stats:     279 lines in 9 files changed: 237 ins; 27 del; 15 mod

8319589: Attach from root to a user java process not supported in Mac

Reviewed-by: sspitsyn

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

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

From iklam at openjdk.org  Mon Dec 15 20:28:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 15 Dec 2025 20:28:17 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
Message-ID: <q4BmjvrFm3_ALV5EhJ_J59ZEiE_JnntbioCSk4zdArI=.a79e7fb2-40aa-4710-b3e5-dd43fbfd1238@github.com>

On Mon, 15 Dec 2025 06:11:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> 
> > When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

The above paragraph is about new commands being added:


int DCmdFactory::register_DCmdFactory(DCmdFactory* factory) {
  MutexLocker ml(DCmdFactory_lock, Mutex::_no_safepoint_check_flag);
  factory->_next = _DCmdFactoryList;
  _DCmdFactoryList = factory;
  if (_send_jmx_notification && !factory->_hidden
      && (factory->_export_flags & DCmd_Source_MBean)) {
    DCmdFactory::push_jmx_notification_request();
  }
  return 0; // Actually, there's no checks for duplicates
}


Which will eventually cause `DiagnosticCommandImpl::createDiagnosticFrameworkNotification()` to be called by HotSpot to dispatch the `Notification`.

I checked older source code like JDK 8, which has a `DCmdFactory::set_enabled()` method but there are no callers. If there had been a way to disable commands dynamically, that has been lost for a very long time.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3657448785

From ayang at openjdk.org  Tue Dec 16 00:19:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Dec 2025 00:19:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
Message-ID: <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>

On Mon, 15 Dec 2025 12:48:18 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

>> @SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)
>
> @albertnetymk Sure.  I will give detailed description here.
> 
> GC?PS MarkSweep?PS Scavenge
> 
> JVM configuraton:  
> -Xmx2g 
> -Xms256M 
> -XX:MetaspaceSize=256m 
> -XX:MaxMetaspaceSize=256m 
> -XX:+PrintGCDateStamps 
> -XX:+PrintGCDetails 
> -XX:-UseAdaptiveSizePolicy 
> -XX:+PrintAdaptiveSizePolicy 
> -XX:+HeapDumpBeforeFullGC 
> -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=export/Logs/ 
> -Xloggc:/export/Logs/gclogs.log 
> 
> JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.
> 
> Problem Description: 
> When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.
> 
> Check List:
> 1. Container has enough place for heap expansion
> 2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion
> 
> GC log sample:
> // Full GC Starting
> [PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
> 2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
> 2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
> 2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174276K->174980K(...

I?m not very familiar with this output format. The following three flags have been superseded by `-Xlog:gc*`:


-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintAdaptiveSizePolicy


Could you try using `-Xlog:gc*` instead? I think that would make it easier for me to understand the issue.

Additionally, the change from `8338977: Parallel: Improve heap resizing heuristics` should have significantly improved adaptive resizing behavior. Running with `-XX:-UseAdaptiveSizePolicy` is not a configuration we recommend. Would it be possible for you to rerun your benchmark using a build that includes `8338977`, with `UseAdaptiveSizePolicy` enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2621257012

From dholmes at openjdk.org  Tue Dec 16 01:08:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 01:08:51 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

> I do think that also entering a critical region is problematic if it is nested.

Isn't nesting critical regions against the rules of using critical regions?

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3658251463

From serguei.spitsyn at oracle.com  Tue Dec 16 03:27:10 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 03:27:10 +0000
Subject: CFV: New Serviceability Group Member: Chris Plummer
Message-ID: <IA1PR10MB6687DAC980B2FB2D33E445E18DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Chris Plummer to Membership in the Serviceability Group.

Chris is a member of Oracle's Serviceability team and has been contributing
to various parts of the JVM for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/93e24378/attachment-0001.htm>

From lmesnik at openjdk.org  Tue Dec 16 03:42:21 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 03:42:21 GMT
Subject: RFR: 8373723: Deadlock with JvmtiTagMap::flush_object_free_events()
Message-ID: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>

The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.

The fix is to block thread to allow safepoints while waiting on the lock.

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

Commit messages:
 - 8373723: Deadlock with JvmtiTagMap::flush_object_free_events()

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

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

From serguei.spitsyn at oracle.com  Tue Dec 16 03:43:10 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 03:43:10 +0000
Subject: CFV: New Serviceability Group Member: Alex Menkov
Message-ID: <IA1PR10MB66875AFA984C30C070DE0D418DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Alex Menkov to Membership in the Serviceability Group.

Alex is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote



Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/bf649acf/attachment.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 03:53:01 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 03:53:01 +0000
Subject: CFV: New Serviceability Group Member: Kevin Walls
Message-ID: <IA1PR10MB6687A7D86F2A9E67C4CD5D978DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Kevin Walls to Membership in the Serviceability Group.

Kevin is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/51556ec0/attachment-0001.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 03:57:42 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 03:57:42 +0000
Subject: CFV: New Serviceability Group Member: Kevin Walls
In-Reply-To: <IA1PR10MB6687A7D86F2A9E67C4CD5D978DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687A7D86F2A9E67C4CD5D978DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB668773A66504A791D3D11D948DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

Vote: yes



Confidential- Oracle Internal

From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Serguei Spitsyn <serguei.spitsyn at oracle.com>
Date: Monday, December 15, 2025 at 7:53?PM
To: serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
Subject: CFV: New Serviceability Group Member: Kevin Walls

I hereby nominate Kevin Walls to Membership in the Serviceability Group.

Kevin is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/ed839296/attachment.htm>

From dholmes at openjdk.org  Tue Dec 16 04:01:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 04:01:00 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>

On Tue, 16 Dec 2025 03:34:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:

> 1206:     {
> 1207:       // If another thread is posting events, let it finish.
> 1208:       // This another thread might have safepoints during event callbacks.

The comment does not read correctly.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:

> 1208:       // This another thread might have safepoints during event callbacks.
> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);

Why not just remove the "no safepoint check" from the MonitorLocker?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2621667991
PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2621668730

From serguei.spitsyn at oracle.com  Tue Dec 16 04:35:12 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 04:35:12 +0000
Subject: CFV: New Serviceability Group Member: Chris Plummer
Message-ID: <IA1PR10MB6687F215B89D529F19F6E9F48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Chris Plummer to Membership in the Serviceability Group.

Chris is a member of Oracle's Serviceability team and has been contributing
to various parts of the JVM for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/d5a5374b/attachment.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 04:40:11 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 04:40:11 +0000
Subject: CFV: New Serviceability Group Member: Alex Menkov
Message-ID: <IA1PR10MB6687C396E9ECE6FBD07BDB1A8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Alex Menkov to Membership in the Serviceability Group.

Alex is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/daed8d1a/attachment-0001.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 04:42:30 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 04:42:30 +0000
Subject: CFV: New Serviceability Group Member: Kevin Walls
Message-ID: <IA1PR10MB66877382E56A98F1AD399C528DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Kevin Walls to Membership in the Serviceability Group.

Kevin is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/7610bcb5/attachment.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 04:45:03 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 04:45:03 +0000
Subject: CFV: New Serviceability Group Member: Leonid Mesnik
Message-ID: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

I hereby nominate Leonid Mesnik to Membership in the Serviceability Group.

Leonid is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/343dc07d/attachment-0001.htm>

From dholmes at openjdk.org  Tue Dec 16 05:45:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 05:45:53 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <e9HrWI-CsO0LmVSwLPp43Gpn0dexy5aMDXT7ChJwpy0=.5106b6d0-9e20-4239-92c9-8522ec01974c@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

For the history see 

https://bugs.openjdk.org/browse/JDK-7104647?focusedId=12336354&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12336354

The "enabled" capability came from the JRockit jrcmd tool:

https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/ctrlbreakhndlr.html

> "You can enable or disable any diagnostic command using the system property -Djrockit.ctrlbreak.enable<name>=<true|false>, where name is the name of the diagnostic command."

But as far as I can see the DCmd framework never specified a mechanism for disabling a DCmd. @fparain may recall more details.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3658938216

From alan.bateman at oracle.com  Tue Dec 16 06:48:16 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2025 06:48:16 +0000
Subject: CFV: New Serviceability Group Member: Chris Plummer
In-Reply-To: <IA1PR10MB6687DAC980B2FB2D33E445E18DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687DAC980B2FB2D33E445E18DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <67dba292-11dd-40b9-a294-c93125d5c78d@oracle.com>

Vote: yes

From alan.bateman at oracle.com  Tue Dec 16 06:48:26 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2025 06:48:26 +0000
Subject: CFV: New Serviceability Group Member: Alex Menkov
In-Reply-To: <IA1PR10MB66875AFA984C30C070DE0D418DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB66875AFA984C30C070DE0D418DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <166aa110-cf70-4824-b512-307f69302c94@oracle.com>

Vote: yes

From alan.bateman at oracle.com  Tue Dec 16 06:48:45 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2025 06:48:45 +0000
Subject: CFV: New Serviceability Group Member: Kevin Walls
In-Reply-To: <IA1PR10MB6687A7D86F2A9E67C4CD5D978DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687A7D86F2A9E67C4CD5D978DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <79d50267-06bc-42b8-ab64-36a4257621c3@oracle.com>

Vote: yes

From alan.bateman at oracle.com  Tue Dec 16 06:49:11 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2025 06:49:11 +0000
Subject: CFV: New Serviceability Group Member: Leonid Mesnik
In-Reply-To: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <99d3b770-7839-46e8-9ede-11829894c6e5@oracle.com>

Vote: yes

From duke at openjdk.org  Tue Dec 16 07:13:09 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Tue, 16 Dec 2025 07:13:09 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
Message-ID: <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>

On Tue, 16 Dec 2025 00:15:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk Sure.  I will give detailed description here.
>> 
>> GC?PS MarkSweep?PS Scavenge
>> 
>> JVM configuraton:  
>> -Xmx2g 
>> -Xms256M 
>> -XX:MetaspaceSize=256m 
>> -XX:MaxMetaspaceSize=256m 
>> -XX:+PrintGCDateStamps 
>> -XX:+PrintGCDetails 
>> -XX:-UseAdaptiveSizePolicy 
>> -XX:+PrintAdaptiveSizePolicy 
>> -XX:+HeapDumpBeforeFullGC 
>> -XX:+HeapDumpOnOutOfMemoryError 
>> -XX:HeapDumpPath=export/Logs/ 
>> -Xloggc:/export/Logs/gclogs.log 
>> 
>> JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.
>> 
>> Problem Description: 
>> When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.
>> 
>> Check List:
>> 1. Container has enough place for heap expansion
>> 2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion
>> 
>> GC log sample:
>> // Full GC Starting
>> [PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
>> 2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
>> 2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
>> 2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomi...
>
> I?m not very familiar with this output format. The following three flags have been superseded by `-Xlog:gc*`:
> 
> 
> -XX:+PrintGCDateStamps
> -XX:+PrintGCDetails
> -XX:+PrintAdaptiveSizePolicy
> 
> 
> Could you try using `-Xlog:gc*` instead? I think that would make it easier for me to understand the issue.
> 
> Additionally, the change from `8338977: Parallel: Improve heap resizing heuristics` should have significantly improved adaptive resizing behavior. Running with `-XX:-UseAdaptiveSizePolicy` is not a configuration we recommend. Would it be possible for you to rerun your benchmark using a build that includes `8338977`, with `UseAdaptiveSizePolicy` enabled?

@albertnetymk Since my JVM's version is 25.191-b12, it does not support `-Xlog:gc*` configuration. I also know that your work aim to improve performance when `UseAdaptiveSizePolicy` enabled, but in my situation default configuration is disable that. Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand. 

-Xmx2g
-Xms256M
-XX:-UseAdaptiveSizePolicy

I understand that's totally not your business, but if you know who can explain or confirm this "bug", just let me know, thx!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2622073234

From serguei.spitsyn at oracle.com  Tue Dec 16 07:45:56 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 07:45:56 +0000
Subject: CFV: New Serviceability Group Member: Chris Plummer
In-Reply-To: <IA1PR10MB6687F215B89D529F19F6E9F48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687F215B89D529F19F6E9F48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB6687E0FD3A937E9DD478BAC48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

Vote: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/81db74cc/attachment.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 07:46:17 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 07:46:17 +0000
Subject: CFV: New Serviceability Group Member: Alex Menkov
In-Reply-To: <IA1PR10MB6687C396E9ECE6FBD07BDB1A8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687C396E9ECE6FBD07BDB1A8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB668713525F110AB7C3026DFB8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

Vote: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/8f5e74d9/attachment.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 07:46:36 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 07:46:36 +0000
Subject: CFV: New Serviceability Group Member: Kevin Walls
In-Reply-To: <IA1PR10MB66877382E56A98F1AD399C528DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB66877382E56A98F1AD399C528DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB6687B7BD5D31339D935DE92F8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>

Vote: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/a412a939/attachment-0001.htm>

From serguei.spitsyn at oracle.com  Tue Dec 16 07:46:59 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 07:46:59 +0000
Subject: CFV: New Serviceability Group Member: Leonid Mesnik
In-Reply-To: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB6687337A6D2BFF7E81DC7B538DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>


Vote: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251216/03284b40/attachment.htm>

From rrich at openjdk.org  Tue Dec 16 08:31:54 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 16 Dec 2025 08:31:54 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
Message-ID: <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>

On Tue, 16 Dec 2025 01:05:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I do think that also entering a critical region is problematic if it is nested.
> 
> Isn't nesting critical regions against the rules of using critical regions?

For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :)
I'll see if I can implement a reproducer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3659373705

From ayang at openjdk.org  Tue Dec 16 11:10:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Dec 2025 11:10:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
 <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
Message-ID: <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>

On Tue, 16 Dec 2025 07:09:55 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

> Since my JVM's version is 25.191-b12 ...

I thought it means JDK25... My apologies.

>  Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand.

I think that behavior is definitely undesirable. Whether or not it's a bug can be subjective.

I believe this behavior has been fixed/improved in later releases of JDK. At least the following two tickets are relevant.

JDK-8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
Use max old-gen capacity to decide whether to start a "proactive" full-gc, instead of young-gc.

JDK-8338977: Parallel: Improve heap resizing heuristics 
In `PSParallelCompact::summary_phase`, old-gen is expanded via `ParallelScavengeHeap::heap()->old_gen()->try_expand_till_size` even with `-XX:-UseAdaptiveSizePolicy`.

I wonder if you can try your benchmark(s) with newer JDKs and check if the problem persists.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2622829786

From sspitsyn at openjdk.org  Tue Dec 16 11:20:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 11:20:07 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v3]
In-Reply-To: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <S1Bhy_-UspkE2k_j1_AB1eqZKn_GkyRK7iL7SCN-uFY=.35089b8c-0af9-4d17-9565-836864925b9c@github.com>

> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
> 
> This is fixed by a small tweak in the function
> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
> 
> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
> 
> Testing:
>  - In progress: mach5 tiers 1-6

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

 - Merge
 - review: restored the assert and fixed the issue caused it to fire
 - 8373366: HandshakeState should disallow suspend ops for disabler threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28740/files
  - new: https://git.openjdk.org/jdk/pull/28740/files/b51267f3..2b088a62

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

  Stats: 35244 lines in 491 files changed: 23171 ins; 9295 del; 2778 mod
  Patch: https://git.openjdk.org/jdk/pull/28740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740

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

From sspitsyn at openjdk.org  Tue Dec 16 11:26:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 11:26:34 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v10]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <rDo9gCaD2-85m2TVwyfBv8PuvUeKpZHqulm66KkNAck=.52321d24-0f17-4524-bcd1-877a72c1315b@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge
 - merge: add fragments dropped by incorrect merge
 - merge: fix merge error
 - Merge
 - Merge
 - review: optimize hide_single_stepping and post_method_exit
 - review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS
 - review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx)
 - review: fix typo in a EATests.java comment
 - cleanup: removed an old code fragment in frame.cpp
 - ... and 1 more: https://git.openjdk.org/jdk/compare/53ebcdbd...8e0164c2

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

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=09
  Stats: 292 lines in 22 files changed: 194 ins; 61 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

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

From dholmes at openjdk.org  Tue Dec 16 11:33:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 11:33:53 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
 <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
Message-ID: <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>

On Tue, 16 Dec 2025 08:29:32 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > > I do think that also entering a critical region is problematic if it is nested.
> > 
> > 
> > Isn't nesting critical regions against the rules of using critical regions?
> 
> For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :) I'll see if I can implement a reproducer.

Right I see that. It states:
> Inside a critical region, native code must not call other JNI functions, ...

but then explicitly allows the critical functions themselves to be an exception. Okay.

So isn't a fix for this simply to skip blocking as per your PR:

 if (is_obj_deopt_suspend() && !in_critical()) {

irrespective of nesting and without any need for any of the changes I proposed?

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660076633

From rrich at openjdk.org  Tue Dec 16 13:01:50 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 16 Dec 2025 13:01:50 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
 <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
 <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>
Message-ID: <mVZqbJRdBQ2CXZ4pbj1DUb6nGzy75dfrINRw1CtoYAA=.823d6b0f-5360-4a1f-bf7c-60402da385b9@github.com>

On Tue, 16 Dec 2025 11:31:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So isn't a fix for this simply to skip blocking as per your PR:
> 
> ```
>  if (is_obj_deopt_suspend() && !in_critical()) {
> ```
> 
> irrespective of nesting and without any need for any of the changes I proposed?

Yes, I currently think so.
Testing so far is good. Don't have a reproducer yet for the deadlock.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660407119

From bkilambi at openjdk.org  Tue Dec 16 13:49:03 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 16 Dec 2025 13:49:03 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
Message-ID: <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>

On Thu, 11 Dec 2025 06:08:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>  I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.

Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3660602956

From sjohanss at openjdk.org  Tue Dec 16 14:04:54 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 16 Dec 2025 14:04:54 GMT
Subject: RFR: 8373625: CPUTimeCounters creates a total counter for
 unsupported GCs
In-Reply-To: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
References: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
Message-ID: <SVIoh3GDVQ7Dzg6-V9ZavFgMA65GIiHvry8X4eJek64=.95bef36a-fe60-4f2a-a678-69ee58fd8f3a@github.com>

On Fri, 12 Dec 2025 21:30:01 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> `CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get
> 
> 
> [7.907s][info][cpu] === CPU time Statistics =============================================================
> [7.907s][info][cpu]                                                                             CPUs
> [7.907s][info][cpu]                                                                s       %  utilized
> [7.907s][info][cpu]    Process
> [7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
> [7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
> [7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
> [7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
> [7.907s][info][cpu] =====================================================================================
> 
> 
> But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

Looks good. 

I was a bit hesitant, but since there are a lot of other "gc cpu counters" just defined for G1 and Parallel I guess this is fine.

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28803#pullrequestreview-3583245272
PR Review: https://git.openjdk.org/jdk/pull/28803#pullrequestreview-3583246794

From tschatzl at openjdk.org  Tue Dec 16 14:09:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 16 Dec 2025 14:09:18 GMT
Subject: RFR: 8373625: CPUTimeCounters creates a total counter for
 unsupported GCs
In-Reply-To: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
References: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
Message-ID: <ND6Seigf7GKLin3uadiGdF3vM9zTJCnCOTHaoPi1vYo=.baf2d6f1-bee6-4381-80d4-92679c0079c1@github.com>

On Fri, 12 Dec 2025 21:30:01 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> `CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get
> 
> 
> [7.907s][info][cpu] === CPU time Statistics =============================================================
> [7.907s][info][cpu]                                                                             CPUs
> [7.907s][info][cpu]                                                                s       %  utilized
> [7.907s][info][cpu]    Process
> [7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
> [7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
> [7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
> [7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
> [7.907s][info][cpu] =====================================================================================
> 
> 
> But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28803#pullrequestreview-3583263681

From duke at openjdk.org  Tue Dec 16 14:18:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 14:18:22 GMT
Subject: RFR: 8373625: CPUTimeCounters creates a total counter for
 unsupported GCs
In-Reply-To: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
References: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
Message-ID: <k8Ma3ERcYjvSIug26AUNPii-2xibAEz1im1kYaSBg9Q=.f350cd2e-6848-4288-8d63-1f9b2c2902de@github.com>

On Fri, 12 Dec 2025 21:30:01 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> `CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get
> 
> 
> [7.907s][info][cpu] === CPU time Statistics =============================================================
> [7.907s][info][cpu]                                                                             CPUs
> [7.907s][info][cpu]                                                                s       %  utilized
> [7.907s][info][cpu]    Process
> [7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
> [7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
> [7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
> [7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
> [7.907s][info][cpu] =====================================================================================
> 
> 
> But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

@JonasNorlinder 
Your change (at version c643db51737c809b39457e95c1f4a568280908c9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28803#issuecomment-3660763052

From fparain at openjdk.org  Tue Dec 16 15:28:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:28:21 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <_vX0iZx2pk5puYThVOlJ3CL8Cv2fketux6_yupud8sc=.be19dfc6-f9ac-40fc-9b8e-5477ec093a5b@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

The "enabled" capability probably fall in the category of features that were initially implemented to emulate JRockit jrcmd  tool but were finally not integrated in HotSpot (I remember another feature like that, to execute an user shell script when some events were triggered).
I don't remember having used or debugged this enable/disable feature. It looks that dead code that have been here for too long. Thank you for having found it and cleaned it up.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661116214

From fparain at openjdk.org  Tue Dec 16 15:40:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:40:25 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

LGTM

More context: https://openjdk.org/jeps/137

> 1-1 Overview
> 
> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. This
  error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.

The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3583740017
PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661165228

From jbhateja at openjdk.org  Tue Dec 16 15:48:06 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Dec 2025 15:48:06 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
 <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
Message-ID: <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>

On Tue, 16 Dec 2025 13:45:58 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> > I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
> 
> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?

Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR.
Best Regards

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3661203155

From kevinw at openjdk.org  Tue Dec 16 20:46:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:46 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <adui1hf3MwZvlgT-cy3RamKYJeVPbtt-yoAXSL6jMLU=.0694d9b5-7d9f-44e4-9f9a-a9315be4d121@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3584868873

From kevinw at openjdk.org  Tue Dec 16 20:46:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:47 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
Message-ID: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>

On Tue, 16 Dec 2025 15:36:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @kevinjwalls comments
>
> More context: https://openjdk.org/jeps/137
> 
>> 1-1 Overview
>> 
>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Thi
 s error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
> 
> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662306936

From jnorlinder at openjdk.org  Tue Dec 16 21:36:44 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 16 Dec 2025 21:36:44 GMT
Subject: Integrated: 8373625: CPUTimeCounters creates a total counter for
 unsupported GCs
In-Reply-To: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
References: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>
Message-ID: <ksRjcR6Mx6987touaXXUkFJxHUJof6bsiaJkWHz_Fy4=.b04b6170-3063-4a08-a346-940b5da4cf3a@github.com>

On Fri, 12 Dec 2025 21:30:01 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> `CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get
> 
> 
> [7.907s][info][cpu] === CPU time Statistics =============================================================
> [7.907s][info][cpu]                                                                             CPUs
> [7.907s][info][cpu]                                                                s       %  utilized
> [7.907s][info][cpu]    Process
> [7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
> [7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
> [7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
> [7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
> [7.907s][info][cpu] =====================================================================================
> 
> 
> But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

This pull request has now been integrated.

Changeset: 30be9408
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30be94086aad42b99a15a05fe5115f552e8efb8b
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8373625: CPUTimeCounters creates a total counter for unsupported GCs

Reviewed-by: sjohanss, tschatzl

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

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

From lmesnik at openjdk.org  Tue Dec 16 21:46:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 21:46:53 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
Message-ID: <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>

On Tue, 16 Dec 2025 03:57:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:
> 
>> 1208:       // This another thread might have safepoints during event callbacks.
>> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
>> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
> 
> Why not just remove the "no safepoint check" from the MonitorLocker?

This is lock is used in different places, including 
`JvmtiTagMap::check_hashmaps_for_heapwalk`
which is called from VMThread. 
Thus JvmtiTagMap_lock can't has rank `safepoint` and this `MonitorLocker` should also has `_no_safepoint_check_flag`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624844825

From dholmes at openjdk.org  Tue Dec 16 22:06:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 22:06:41 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
Message-ID: <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>

On Tue, 16 Dec 2025 03:56:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:
> 
>> 1206:     {
>> 1207:       // If another thread is posting events, let it finish.
>> 1208:       // This another thread might have safepoints during event callbacks.
> 
> The comment does not read correctly.

Suggestion:

// The other thread can block for safepoints during event callbacks, so ensure we
// are safepoint-safe while waiting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624903690

From dholmes at openjdk.org  Tue Dec 16 22:06:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 22:06:43 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
 <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>
Message-ID: <qr2YEUQTF-ctJnk6BCiEzXaRlLAzXRrjGmV12QlWPHg=.04a9dee9-07a7-4bcf-82cb-913b6efe544a@github.com>

On Tue, 16 Dec 2025 21:44:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:
>> 
>>> 1208:       // This another thread might have safepoints during event callbacks.
>>> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
>>> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
>> 
>> Why not just remove the "no safepoint check" from the MonitorLocker?
>
> This is lock is used in different places, including 
> `JvmtiTagMap::check_hashmaps_for_heapwalk`
> which is called from VMThread. 
> Thus JvmtiTagMap_lock can't has rank `safepoint` and this `MonitorLocker` should also has `_no_safepoint_check_flag`.

Okay. It does seem like the one case of waiting for event posting to complete, is the only place we need to be safepoint-safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624900432

From lmesnik at openjdk.org  Tue Dec 16 23:08:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 23:08:24 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  applid David's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28839/files
  - new: https://git.openjdk.org/jdk/pull/28839/files/3035f2b4..6790f159

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

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

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

From lmesnik at openjdk.org  Tue Dec 16 23:08:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 23:08:25 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
 <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>
Message-ID: <kx14xotDQMrXNWb3MRyftYQLcoo2iXJDDU1yIvMPMMc=.320c7043-748f-472c-82a1-eba6f59d3ba5@github.com>

On Tue, 16 Dec 2025 22:04:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:
>> 
>>> 1206:     {
>>> 1207:       // If another thread is posting events, let it finish.
>>> 1208:       // This another thread might have safepoints during event callbacks.
>> 
>> The comment does not read correctly.
>
> Suggestion:
> 
> // The other thread can block for safepoints during event callbacks, so ensure we
> // are safepoint-safe while waiting.

Thank you for your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2625038070

From lmesnik at openjdk.org  Tue Dec 16 23:14:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 23:14:28 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v3]
In-Reply-To: <S1Bhy_-UspkE2k_j1_AB1eqZKn_GkyRK7iL7SCN-uFY=.35089b8c-0af9-4d17-9565-836864925b9c@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <S1Bhy_-UspkE2k_j1_AB1eqZKn_GkyRK7iL7SCN-uFY=.35089b8c-0af9-4d17-9565-836864925b9c@github.com>
Message-ID: <Jui6x0gIz1nEOfaq_V3fTXPA6iKcmgL-9enn8jw7Ols=.28d3c74a-696c-48d9-90f0-0bf3299b8794@github.com>

On Tue, 16 Dec 2025 11:20:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - review: restored the assert and fixed the issue caused it to fire
>  - 8373366: HandshakeState should disallow suspend ops for disabler threads

Thank you for explanations.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3585331471

From iklam at openjdk.org  Tue Dec 16 23:20:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:26 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
 <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
Message-ID: <vQrQ9PNZaSzfCfw4AZQe8pnUGIAB5FvAOncqzxguvlo=.9f26b5e8-a211-4856-b110-b0d220cc8880@github.com>

On Tue, 16 Dec 2025 20:43:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> More context: https://openjdk.org/jeps/137
>> 
>>> 1-1 Overview
>>> 
>>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Th
 is error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
>> 
>> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).
>
> Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

Thanks @kevinjwalls @fparain @kevinjwalls for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662832242

From iklam at openjdk.org  Tue Dec 16 23:20:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:27 GMT
Subject: Integrated: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <RxByniX_b6rPrJESSqHi8WN2TJ1LdVqZJIfkBxNUjrM=.c1747871-bc12-45fa-9b42-56c1975b0d8f@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

This pull request has now been integrated.

Changeset: 3f077102
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f07710270dbe7268f21828dff20e2eb810b1e70
Stats:     102 lines in 7 files changed: 4 ins; 25 del; 73 mod

8373441: Remove DCmdFactory::_enabled

Reviewed-by: kevinw, fparain, jsjolen

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

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

From sspitsyn at openjdk.org  Wed Dec 17 05:34:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Dec 2025 05:34:24 GMT
Subject: [jdk26] RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
Message-ID: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>

Please, review a jdk 26 test fix backport. This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
This changeset was reviewed by [Leonid Mesnik](https://openjdk.org/census#lmesnik) and [Alex Menkov](https://openjdk.org/census#amenkov) .

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

Commit messages:
 - Backport c46bed7292aad21b8cf9defcccac43c010a1f116

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

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

From lmesnik at openjdk.org  Wed Dec 17 05:59:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Dec 2025 05:59:52 GMT
Subject: [jdk26] RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
References: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
Message-ID: <UJDRXAlQbc_knirgLRQBVQ1XYnYmA-qdo2p2sZAiF9o=.5afb2c89-7258-4209-a77e-877614936574@github.com>

On Wed, 17 Dec 2025 05:26:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 test fix backport. This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Leonid Mesnik](https://openjdk.org/census#lmesnik) and [Alex Menkov](https://openjdk.org/census#amenkov) .

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28859#pullrequestreview-3586127520

From sspitsyn at openjdk.org  Wed Dec 17 08:14:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Dec 2025 08:14:41 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v4]
In-Reply-To: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>

> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
> 
> This is fixed by a small tweak in the function
> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
> 
> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
> 
> Testing:
>  - In progress: mach5 tiers 1-6

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

  review: replace fix with just one assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28740/files
  - new: https://git.openjdk.org/jdk/pull/28740/files/2b088a62..d1f391b4

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

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

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

From sspitsyn at openjdk.org  Wed Dec 17 08:25:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Dec 2025 08:25:00 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v4]
In-Reply-To: <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
Message-ID: <Y5Ciplql__rbS92MFoGEguJe9dgv_fDEoLI4daxai8A=.394033a1-21e3-4611-b465-9d0b4959f953@github.com>

On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace fix with just one assert

Replaced the fix with one simple assert. It did not fire in mach5 tiers 1-6. Will do more test runs though.
The suggestion is to keep this assert until we discover it ever failing. If it happens then we could return to the original fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3664195008

From duke at openjdk.org  Wed Dec 17 10:29:08 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Wed, 17 Dec 2025 10:29:08 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
 <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
 <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>
Message-ID: <-l_zOUn6BoYsrRF-0W1Dl581XtE-TEPXiXhadRiMPHs=.dfbf70eb-0f54-4485-a967-befd6269edaf@github.com>

On Tue, 16 Dec 2025 11:07:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk Since my JVM's version is 25.191-b12, it does not support `-Xlog:gc*` configuration. I also know that your work aim to improve performance when `UseAdaptiveSizePolicy` enabled, but in my situation default configuration is disable that. Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand. 
>> 
>> -Xmx2g
>> -Xms256M
>> -XX:-UseAdaptiveSizePolicy
>> 
>> I understand that's totally not your business, but if you know who can explain or confirm this "bug", just let me know, thx!
>
>> Since my JVM's version is 25.191-b12 ...
> 
> I thought it means JDK25... My apologies.
> 
>>  Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand.
> 
> I think that behavior is definitely undesirable. Whether or not it's a bug can be subjective.
> 
> I believe this behavior has been fixed/improved in later releases of JDK. At least the following two tickets are relevant.
> 
> JDK-8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
> Use max old-gen capacity to decide whether to start a "proactive" full-gc, instead of young-gc.
> 
> JDK-8338977: Parallel: Improve heap resizing heuristics 
> In `PSParallelCompact::summary_phase`, old-gen is expanded via `ParallelScavengeHeap::heap()->old_gen()->try_expand_till_size` even with `-XX:-UseAdaptiveSizePolicy`.
> 
> I wonder if you can try your benchmark(s) with newer JDKs and check if the problem persists.

Thanks! I thinks these two ticket solved the problem I met, which means newer version JDK will not have this issue any more?. @albertnetymk

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2626467932

From aturbanov at openjdk.org  Wed Dec 17 10:43:54 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 17 Dec 2025 10:43:54 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests
In-Reply-To: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
Message-ID: <9vaoIacqeQtaDtLMMicjQ5L2TqbqgPFasZBuIT7-t2M=.4ad31447-cf97-4081-bcdc-65c57baf88af@github.com>

On Mon, 15 Dec 2025 14:27:14 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
> 
> Thanks!

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 293:

> 291:      */
> 292:     public static void removeDockerImage(String imageNameAndTag) throws Exception {
> 293:         if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) {

Suggestion:

        if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28826#discussion_r2626526625

From kevin.walls at oracle.com  Wed Dec 17 11:01:49 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 17 Dec 2025 11:01:49 +0000
Subject: CFV: New Serviceability Group Member: Alex Menkov
In-Reply-To: <IA1PR10MB6687C396E9ECE6FBD07BDB1A8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687C396E9ECE6FBD07BDB1A8DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <DM3PPF1D4534BE41F99AA20F3830915D93E97ABA@DM3PPF1D4534BE4.namprd10.prod.outlook.com>

Vote: yes
________________________________
From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Serguei Spitsyn <serguei.spitsyn at oracle.com>
Sent: Tuesday, December 16, 2025 4:40 AM
To: serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
Subject: CFV: New Serviceability Group Member: Alex Menkov

I hereby nominate Alex Menkov to Membership in the Serviceability Group.

Alex is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251217/161bf053/attachment-0001.htm>

From kevin.walls at oracle.com  Wed Dec 17 11:02:04 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 17 Dec 2025 11:02:04 +0000
Subject: CFV: New Serviceability Group Member: Chris Plummer
In-Reply-To: <IA1PR10MB6687F215B89D529F19F6E9F48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687F215B89D529F19F6E9F48DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <DM3PPF1D4534BE4E05772F2D4F20E89773897ABA@DM3PPF1D4534BE4.namprd10.prod.outlook.com>

Vote: yes

________________________________
From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Serguei Spitsyn <serguei.spitsyn at oracle.com>
Sent: Tuesday, December 16, 2025 4:35 AM
To: serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
Subject: CFV: New Serviceability Group Member: Chris Plummer

I hereby nominate Chris Plummer to Membership in the Serviceability Group.

Chris is a member of Oracle's Serviceability team and has been contributing
to various parts of the JVM for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251217/69f4b346/attachment.htm>

From kevin.walls at oracle.com  Wed Dec 17 11:02:17 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 17 Dec 2025 11:02:17 +0000
Subject: CFV: New Serviceability Group Member: Leonid Mesnik
In-Reply-To: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
References: <IA1PR10MB6687A422C496C90723071CF68DAAA@IA1PR10MB6687.namprd10.prod.outlook.com>
Message-ID: <DM3PPF1D4534BE4FACA3250919EC13B4FEE97ABA@DM3PPF1D4534BE4.namprd10.prod.outlook.com>

Vote: yes
________________________________
From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Serguei Spitsyn <serguei.spitsyn at oracle.com>
Sent: Tuesday, December 16, 2025 4:45 AM
To: serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
Subject: CFV: New Serviceability Group Member: Leonid Mesnik

I hereby nominate Leonid Mesnik to Membership in the Serviceability Group.

Leonid is a member of Oracle's Serviceability team and has been contributing
to various parts of the Serviceability for many years now.

Votes are due by December 30, 2025, 07:00 PST.

Only current Members of the Serviceability Group [0] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [1].

Thanks,
Serguei

[0] https://openjdk.org/census
[1] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20251217/86e9351c/attachment-0001.htm>

From mablakatov at openjdk.org  Wed Dec 17 11:43:25 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Wed, 17 Dec 2025 11:43:25 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
Message-ID: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>

nmethod objects in the CodeCache have the following layout:


| CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops |


Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density.

This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is:


| CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops |


This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint.

This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.

## Testing

The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64.

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

Commit messages:
 - 8373794: Move nmethod header from CodeCache:

Changes: https://git.openjdk.org/jdk/pull/28866/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28866&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373794
  Stats: 625 lines in 17 files changed: 168 ins; 15 del; 442 mod
  Patch: https://git.openjdk.org/jdk/pull/28866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28866/head:pull/28866

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

From syan at openjdk.org  Wed Dec 17 11:52:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Dec 2025 11:52:45 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests [v2]
In-Reply-To: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
Message-ID: <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
> 
> Thanks!

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

  Add an whitespace after if
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28826/files
  - new: https://git.openjdk.org/jdk/pull/28826/files/d66b7695..ae10ac54

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

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

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

From jbhateja at openjdk.org  Wed Dec 17 12:56:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 Dec 2025 12:56:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Including test changes from Bhavana Kilambi (ARM)
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Optimizing tail handling
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Fix failing jtreg test in CI
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d

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

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 515408 lines in 232 files changed: 284464 ins; 229217 del; 1727 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From ysuenaga at openjdk.org  Wed Dec 17 13:34:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 17 Dec 2025 13:34:06 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <YBEbixB96rmsyRVz6ceE1DKyPEjjS4bgQvXDgXsIRew=.ea36054b-3769-491a-b627-5ad08ca410a2@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

PING: Can I get second reviewer(s)? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3665374088

From ysuenaga at openjdk.org  Wed Dec 17 13:34:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 17 Dec 2025 13:34:40 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
Message-ID: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>

We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.


$ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
[38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
2025-12-17 06:34:37
Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):

Threads class SMR info:
_java_thread_list=0x000078a8bc13f200, length=10, elements={
0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
   :


Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).

In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:


$ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
/ # /usr/lib/jvm/jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)

/ # ls -l /proc/1/cwd
ls: /proc/1/cwd: cannot read link: Permission denied
lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd



After this change, we can see following exception on the console of jcmd when we encounter this situation:

# jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Caused by: java.nio.file.AccessDeniedException: /proc/1/root/tmp
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
        at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
        at java.base/java.nio.file.Files.isSameFile(Files.java:1418)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:275)
        ... 6 more


This change passed jdk/com/sun/tools/attach tests on Linux AMD64

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

Commit messages:
 - 8373867: Improve robustness of Attach API for finding tmp directory

Changes: https://git.openjdk.org/jdk/pull/28867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373867
  Stats: 36 lines in 2 files changed: 21 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28867/head:pull/28867

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

From lmesnik at openjdk.org  Wed Dec 17 15:49:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Dec 2025 15:49:02 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v4]
In-Reply-To: <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
Message-ID: <D62Zp_757eu9mCopT_B3iaPBU_TWtyuuamHSKohAWaE=.1c5180b9-b954-463c-9c2c-6b26dd4bf04c@github.com>

On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace fix with just one assert

I think better replaces text with something non-TMP.

Also, might be worth add comment for ThreadSelfSuspensionHandshakeClosure somewhere.  This comment should explain the connection of this
ThreadSelfSuspension handshake and  SuspendThreadHandshake.
Ie there shouldn't safepoint between  `SuspendResumeManager::suspend_with_handshake` and processing ThreadSelfSuspensionHandshake. It should help to understand why suspended thread thread can't be in disabler now.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3588376322

From duke at openjdk.org  Wed Dec 17 16:30:20 2025
From: duke at openjdk.org (Larry Cable)
Date: Wed, 17 Dec 2025 16:30:20 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <xSB7uEUCPFhu83j3oaBDuACRa9ALCxIdwd-hJH2heE8=.7f6c280c-be8d-41c7-b23d-30db0b9f8cd1@github.com>

On Wed, 17 Dec 2025 11:39:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

looks good!

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3666152662

From amenkov at openjdk.org  Wed Dec 17 18:28:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 17 Dec 2025 18:28:37 GMT
Subject: [jdk26] RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
References: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
Message-ID: <u484O71fkN305dNuiuggFWKr9waDJk3Empg9kGYGNFI=.b128b1b9-19e0-45fc-90c7-cff04b712310@github.com>

On Wed, 17 Dec 2025 05:26:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 test fix backport. This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Leonid Mesnik](https://openjdk.org/census#lmesnik) and [Alex Menkov](https://openjdk.org/census#amenkov) .

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28859#pullrequestreview-3589067645

From kevinw at openjdk.org  Wed Dec 17 18:33:37 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 17 Dec 2025 18:33:37 GMT
Subject: RFR: 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring:
 -iterations setting misused in tests
Message-ID: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>

Some tests in test/hotspot/jtreg/vmTestbase/nsk tests are misusing the -iterations command-line option:  it is parsed only as "-iterations x" rather than "-iterations=x"

Fixing the RunParams parsing to recognise this saves updating multiple tests.

Other options are "option=value" so accepting -iterations=number is what we might expect (and is what tests are currently written to use).

The change makes logs look correct.  No more "Iterations: 0".

There are tests that currently log "Iterations: 0" but still do some work, so this is partly cosmetic, but also if you were thinking of making a test do some set limited number of iterations, you can now follow the example of other tests and have it work.

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

Commit messages:
 - 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring: -iterations setting misused in tests

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

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

From kevinw at openjdk.org  Wed Dec 17 19:09:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 17 Dec 2025 19:09:47 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <LxlZqBwg0DR8neuhyD8r5u1N2zirp-WbPIeBnmQKPnA=.5d109e02-b0c5-4e11-b902-f4a932de8165@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 99:

> 97:         CodeBlob currentBlob = cc.findBlobUnsafe(pc());
> 98: 
> 99:         // This case is different from HotSpot. See JDK-8371194 for details.

Looks good overall I think. 
What does "different from HotSpot" mean?
I see we used that phrase in 8371194 also in LinuxAARCH64CFrame.java
Maybe it is saying that these codeBlobs are handled differently from other code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2628306028

From sspitsyn at openjdk.org  Wed Dec 17 19:32:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Dec 2025 19:32:08 GMT
Subject: [jdk26] RFR: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
References: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
Message-ID: <Ge_HYpfnWKZq3v79LrRa5CwtSPZEG7H9BH3pilrugdc=.5af8e018-d425-47d0-8566-28955af4c243@github.com>

On Wed, 17 Dec 2025 05:26:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 test fix backport. This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Leonid Mesnik](https://openjdk.org/census#lmesnik) and [Alex Menkov](https://openjdk.org/census#amenkov) .

Thank you for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28859#issuecomment-3666831376

From sspitsyn at openjdk.org  Wed Dec 17 19:32:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Dec 2025 19:32:09 GMT
Subject: [jdk26] Integrated: 8371502:
 serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java
 failing
In-Reply-To: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
References: <l9bMVMxBvQyiXadRy-acOOiUhWoxbeyPQJdmYzyroIM=.d660191a-b328-4cf4-afc9-c992a503be58@github.com>
Message-ID: <BaLd7PEictaxBSeUuof-d2L4S2gtJqTAquF4Gco58IE=.6bf8df5f-0eca-4f90-a8ab-441da99c4b86@github.com>

On Wed, 17 Dec 2025 05:26:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 test fix backport. This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/c46bed7292aad21b8cf9defcccac43c010a1f116 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Leonid Mesnik](https://openjdk.org/census#lmesnik) and [Alex Menkov](https://openjdk.org/census#amenkov) .

This pull request has now been integrated.

Changeset: b8b44931
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8b44931174ade129aae58c07e1cebb5c9e0180a
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8371502: serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java failing

Reviewed-by: lmesnik, amenkov
Backport-of: c46bed7292aad21b8cf9defcccac43c010a1f116

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

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

From cjplummer at openjdk.org  Wed Dec 17 20:52:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Dec 2025 20:52:41 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
Message-ID: <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>

On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> nmethod objects in the CodeCache have the following layout:
> 
> 
> | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops |
> 
> 
> Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density.
> 
> This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is:
> 
> 
> | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops |
> 
> 
> This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint.
> 
> This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.
> 
> ## Testing
> 
> The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64.

The SA changes look ok, but you'll need to do some testing by hand. The existing SA tests don't do a good job of testing compiler support. Specifically,  you should run the clhsdb "livenmethods" and "dumpcodecache" commands and make sure the output looks reasonable. Note you may see an issue with "dumpcodecache" getting stuck after producing some output. You can ignore that. I just filed [JDK-8373933](https://bugs.openjdk.org/browse/JDK-8373933) for it.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 104:

> 102: 
> 103:     sun.jvm.hotspot.types.Field f = type.getField("_speculations_offset", false, false);
> 104:     if (f != null) {

Why is there a need for a null check here?

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

PR Review: https://git.openjdk.org/jdk/pull/28866#pullrequestreview-3588754711
PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2627897856

From dholmes at openjdk.org  Wed Dec 17 21:23:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 21:23:48 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28839#pullrequestreview-3589724147

From dholmes at openjdk.org  Wed Dec 17 21:32:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 21:32:33 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <6Suuy1lWRKVyMBTgqxecKvIoHRnZwakNswyhHR09CFs=.3addbcfb-628c-4d61-b29b-83964436cc1b@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

I tested tiers 1-6 with the simplified fix and nothing has turned up.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667274570

From rrich at openjdk.org  Thu Dec 18 00:14:21 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Dec 2025 00:14:21 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <ygHQH4Rzb4oK6rmpERi561IezMZjDLSd5uF2ALUy2Kw=.1c16facd-cbcb-4ab5-b6d4-3c57ffff35c8@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

Thanks! Same with my testing.
I doubt that I'll find the time to write a reproducer though.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667664024

From ysuenaga at openjdk.org  Thu Dec 18 00:19:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 00:19:50 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <LxlZqBwg0DR8neuhyD8r5u1N2zirp-WbPIeBnmQKPnA=.5d109e02-b0c5-4e11-b902-f4a932de8165@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
 <LxlZqBwg0DR8neuhyD8r5u1N2zirp-WbPIeBnmQKPnA=.5d109e02-b0c5-4e11-b902-f4a932de8165@github.com>
Message-ID: <ibIHrJkvp0bGFJd5-o2gAoChmHDVy87cJlkxL0w_FK4=.0192ee00-c032-44ca-8789-1d6ab374331f@github.com>

On Wed, 17 Dec 2025 19:06:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check RBP
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 99:
> 
>> 97:         CodeBlob currentBlob = cc.findBlobUnsafe(pc());
>> 98: 
>> 99:         // This case is different from HotSpot. See JDK-8371194 for details.
> 
> Looks good overall I think. 
> What does "different from HotSpot" mean?
> I see we used that phrase in 8371194 also in LinuxAARCH64CFrame.java
> Maybe it is saying that these codeBlobs are handled differently from other code?

Yes. We were trying to implement similar code with NativeStackPrinter used in generating hs_err log in HotSpot, but this condition is different with it.

Comments in 8371195 says:
> The special case for currentBlob.isContinuationStub() || currentBlob.isNativeMethod()) is needed compared to os::get_sender_for_C_frame because, unlike in the VM, here we are walking those frames as native C frames. Without the special case we depend on nextFP which might not be valid unless -XX:+PreserveFramePointer is used.

In os_bsd_aarch64.cpp, comment of `get_sender_for_C_frame()` says JVM compiled with `-fno-omit-frame-pointer`, but we can override `CFLAGS` with configure options. Thus I think it is better to align with Linux AArch64. Actually I heard this code works fine on Mac AArch64 - mixed jstack unwinded native methods successfully like `java.lang.ref.Reference.waitForReferencePendingList()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2629035449

From dholmes at openjdk.org  Thu Dec 18 01:21:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 01:21:17 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

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

 - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
 - Merge branch 'master' into 8369515-jni-critical
 - Revert "8369515"
   
   This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
 - 8369515

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28779/files
  - new: https://git.openjdk.org/jdk/pull/28779/files/3beb23cc..b96a9bc2

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

  Stats: 12369 lines in 431 files changed: 7742 ins; 1537 del; 3090 mod
  Patch: https://git.openjdk.org/jdk/pull/28779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779

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

From dholmes at openjdk.org  Thu Dec 18 01:43:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 01:43:50 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions
Message-ID: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>

To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 

The mechanism for this already exists courtesy of the virtual thread support.

Testing:
 - tiers 1 - 6 sanity

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

Commit messages:
 - 8373839: Disable JVM TI suspension during JNI critical regions

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

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

From coleenp at openjdk.org  Thu Dec 18 02:08:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 02:08:32 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <f8v5ZiTkeOEQAv6uDKBQZ7iZg9h6AldWCBauRtTUM2Y=.5612bfc6-84dc-492c-83af-61924f46c7ec@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

This looks good.  Was there a test case that can be added?  Or is it noreg-hard?

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28839#pullrequestreview-3590388366

From dlong at openjdk.org  Thu Dec 18 02:26:25 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Dec 2025 02:26:25 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
Message-ID: <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>

On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> nmethod objects in the CodeCache have the following layout:
> 
> 
> | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops |
> 
> 
> Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density.
> 
> This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is:
> 
> 
> | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops |
> 
> 
> This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint.
> 
> This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.
> 
> ## Testing
> 
> The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64.

Wouldn't it be better to move the whole CodeBlob header out of the code cache?  Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

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

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3668010082

From lmesnik at openjdk.org  Thu Dec 18 04:22:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:22:52 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <M2jayhvvkzTBjR9nBJn-l8j7bi4XdUIRypKqK5_x1ck=.91f810d1-0b06-4b10-b710-8c09bc6d67eb@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

The failure reproduced with vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.java
Not very often though.

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

PR Comment: https://git.openjdk.org/jdk/pull/28839#issuecomment-3668292624

From lmesnik at openjdk.org  Thu Dec 18 04:30:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:30:02 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
 <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>
Message-ID: <tTcTRV6F31F7npwfdyATQXgz_0K2VFQLPVGYzK7EYG0=.b7a265e2-4c5b-47e0-907a-af5a0f2da692@github.com>

On Wed, 17 Dec 2025 21:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applid David's suggestion
>
> Looks good. Thanks

@dholmes-ora, @coleenp Thank you for review and fedback!

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

PR Comment: https://git.openjdk.org/jdk/pull/28839#issuecomment-3668305965

From lmesnik at openjdk.org  Thu Dec 18 04:30:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:30:04 GMT
Subject: Integrated: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <A2TDfxtYoUu30H_cM_63pn5SLZUQ-rVtcW0fEUIC3Yw=.80c84e36-3065-41c8-84ca-c7f259c6d591@github.com>

On Tue, 16 Dec 2025 03:34:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

This pull request has now been integrated.

Changeset: 0146077a
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0146077a51635500de771e9cf2c9788ae931b7a0
Stats:     4 lines in 1 file changed: 3 ins; 1 del; 0 mod

8373723: Deadlock with JvmtiTagMap::flush_object_free_events()

Reviewed-by: dholmes, coleenp

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

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

From dholmes at openjdk.org  Thu Dec 18 04:36:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 04:36:54 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v4]
In-Reply-To: <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
Message-ID: <GAlogwnN7y7jIhmeVF_IPSdEylEnUgXTWkqeHoHCUbk=.5f8fdec6-c925-4b1b-bc12-1cb3f9666d0e@github.com>

On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace fix with just one assert

If all you are doing is adding an assert then the JBS issue and the PR need a considerable rewrite to explain things.

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

PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3668324985

From syan at openjdk.org  Thu Dec 18 06:30:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 18 Dec 2025 06:30:00 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests [v2]
In-Reply-To: <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
 <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
Message-ID: <DkLzIUh7u9opP-07njxwYSgzYFZBfJHRPgr9VR5HB_E=.419fffc9-0c96-43b9-81bc-7b55377c6acc@github.com>

On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
>> 
>> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly.
>> 
>> Thanks!
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an whitespace after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Change has been verified locally on linux-x64. This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly.

Verify command:


j -Djdk.test.docker.image.name=jdk-build -Djdk.test.docker.image.version=11 -conc:20 $(git status -s | awk '{print $NF}' | sed "/ockerTestUtils.java/d" | xargs)

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

PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3668601523

From kevinw at openjdk.org  Thu Dec 18 09:20:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Dec 2025 09:20:25 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <rnFeUobog-FTLyhbOZVRNmu7qxi-8US7cbdI9SClYVk=.4b02f3b2-b159-44e9-8819-0a0677428ec0@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28686#pullrequestreview-3591630915

From kevinw at openjdk.org  Thu Dec 18 09:20:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Dec 2025 09:20:28 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <ibIHrJkvp0bGFJd5-o2gAoChmHDVy87cJlkxL0w_FK4=.0192ee00-c032-44ca-8789-1d6ab374331f@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
 <LxlZqBwg0DR8neuhyD8r5u1N2zirp-WbPIeBnmQKPnA=.5d109e02-b0c5-4e11-b902-f4a932de8165@github.com>
 <ibIHrJkvp0bGFJd5-o2gAoChmHDVy87cJlkxL0w_FK4=.0192ee00-c032-44ca-8789-1d6ab374331f@github.com>
Message-ID: <i3NGFEgcRqZqRb_3ZtCvxdmvCbeoeJ89P7QO9pUeavE=.08c69db1-4fe9-4cf0-aac4-edbf72a2238e@github.com>

On Thu, 18 Dec 2025 00:17:02 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java line 99:
>> 
>>> 97:         CodeBlob currentBlob = cc.findBlobUnsafe(pc());
>>> 98: 
>>> 99:         // This case is different from HotSpot. See JDK-8371194 for details.
>> 
>> Looks good overall I think. 
>> What does "different from HotSpot" mean?
>> I see we used that phrase in 8371194 also in LinuxAARCH64CFrame.java
>> Maybe it is saying that these codeBlobs are handled differently from other code?
>
> Yes. We were trying to implement similar code with NativeStackPrinter used in generating hs_err log in HotSpot, but this condition is different with it.
> 
> Comments in 8371195 says:
>> The special case for currentBlob.isContinuationStub() || currentBlob.isNativeMethod()) is needed compared to os::get_sender_for_C_frame because, unlike in the VM, here we are walking those frames as native C frames. Without the special case we depend on nextFP which might not be valid unless -XX:+PreserveFramePointer is used.
> 
> In os_bsd_aarch64.cpp, comment of `get_sender_for_C_frame()` says JVM compiled with `-fno-omit-frame-pointer`, but we can override `CFLAGS` with configure options. Thus I think it is better to align with Linux AArch64. Actually I heard this code works fine on Mac AArch64 - mixed jstack unwinded native methods successfully like `java.lang.ref.Reference.waitForReferencePendingList()`.

OK, so this is different to the HotSpot NativeStackPrinter and the frame::next_frame() method.
As we already have the comment in a similar method maybe no need to change it here.
Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28686#discussion_r2630228294

From fbredberg at openjdk.org  Thu Dec 18 09:22:39 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 18 Dec 2025 09:22:39 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
Message-ID: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>

On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>  - Merge branch 'master' into 8369515-jni-critical
>  - Revert "8369515"
>    
>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>  - 8369515

Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you!

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

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3591638468

From duke at openjdk.org  Thu Dec 18 10:47:09 2025
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 18 Dec 2025 10:47:09 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>

On Wed, 17 Dec 2025 11:39:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518). It's failing in some of Oracle's CI but I have not been able to reproduce the failure myself. It was discussed a bit in https://github.com/openjdk/jdk/pull/21331 too.

I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3669645057

From mablakatov at openjdk.org  Thu Dec 18 11:46:01 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 18 Dec 2025 11:46:01 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
Message-ID: <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>

On Wed, 17 Dec 2025 17:14:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> nmethod objects in the CodeCache have the following layout:
>> 
>> 
>> | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops |
>> 
>> 
>> Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density.
>> 
>> This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is:
>> 
>> 
>> | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops |
>> 
>> 
>> This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint.
>> 
>> This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.
>> 
>> ## Testing
>> 
>> The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 104:
> 
>> 102: 
>> 103:     sun.jvm.hotspot.types.Field f = type.getField("_speculations_offset", false, false);
>> 104:     if (f != null) {
> 
> Why is there a need for a null check here?

`_speculations_offset` is present only when JVM is compiled with JVMCI enabled, see https://github.com/openjdk/jdk/pull/28866/files/bbb3711df942ec48b0b0a6eeb287f5364afa9098#diff-ccbdfe031dfc301041cac88f76f8eb2dcacff1b9f81c50073de5c6eaeb8b8223R256 . `type.getCIntegerField("_speculations_offset")` will throw an exception if the field is missing.

Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2630716509

From ysuenaga at openjdk.org  Thu Dec 18 12:22:51 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 12:22:51 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <63OA-pI-27nHC5kG7108s_BQRxDYH55MX1LhNNbEfVM=.91f3d690-b025-449c-9231-f14a8f2f04cc@github.com>

On Wed, 17 Dec 2025 11:39:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

I haven't installed Docker but I have Podman, so I tested as following. Unfortunately TestJcmdWithSideCar.java still failed due to timeout. It might be different problem with this.


make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=JAVA_OPTIONS=-Djdk.test.container.command=podman

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3670021182

From bkilambi at openjdk.org  Thu Dec 18 12:44:53 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 18 Dec 2025 12:44:53 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
 <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
 <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>
Message-ID: <5NNS6uN_GhivBLv-OhE1Tn0HJhrL6-TKlsN9wWKOytU=.d36bafc2-a5c4-4878-920c-6707cf3547bb@github.com>

On Tue, 16 Dec 2025 15:45:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>>  I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
>> 
>> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?
>
>> > I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
>> 
>> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?
> 
> Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR.
> Best Regards

Thanks @jatin-bhateja for including AArch64 changes to the patch. Also @TobiHartmann suggested (here - https://bugs.openjdk.org/browse/JDK-8373574) that it'd be good to have a regression test for the AArch64 failures. I have put together a small JTREG test taking one of the VectorAPI tests from `TestFloat16VectorOperations.java` introduced in this PR (which was the one failing on AArch64). Could you please include the testcase as well? The patch is attached here
[test.patch](https://github.com/user-attachments/files/24235556/test.patch)

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3670100491

From suenaga at oss.nttdata.com  Thu Dec 18 13:04:30 2025
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 22:04:30 +0900
Subject: Test failure in TestJcmdWithSideCar.java
Message-ID: <9a2b8de506ccf43f00a9d37e1c94698f@oss.nttdata.com>

Hi,

I'm working on JDK-28867 ( https://github.com/openjdk/jdk/pull/28867 ), 
and @slovdahl said this PR might fix the failure in 
TestJcmdWithSideCar.java which has been recorded in ProblemList. 
Unfortunately this PR fix that problem, but I found the cause of 
failure, so I will tell it to the maillist.

The cause is mismatch container base image and OS of build host.

I'm using Fedora 43 to build OpenJDK, however container test would use 
ubuntu:latest image by default.
Thus I saw error in dynamic linker in .jtr file as following. It is why 
main container wasn't started.

```
[main-container-process] Error: dl failure on line 532
[main-container-process] Error: failed /jdk/lib/server/libjvm.so, 
because /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_ABI_GNU2_TLS' 
not found (required by /jdk/lib/server/libjvm.so)
```

The test passed when I added both -Djdk.test.docker.image.name 
-Djdk.test.docker.image.version as following.

```
make test 
TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java 
JTREG="JAVA_OPTIONS=-Djdk.test.container.command=podman 
-Djdk.test.docker.image.name=fedora -Djdk.test.docker.image.version=43"
```


Thus it is an environment problem. Not a bug.


Thanks,

Yasumasa

From ysuenaga at openjdk.org  Thu Dec 18 13:09:21 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 13:09:21 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>
Message-ID: <Kwk3wW07aJGKj57Et4MJBUt1iLel0wHF_VtDVfp0_4k=.8b9963cb-ef2f-484f-ac36-61b37820fdc4@github.com>

On Thu, 18 Dec 2025 10:44:33 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518). It's failing in some of Oracle's CI but I have not been able to reproduce the failure myself. It was discussed a bit in https://github.com/openjdk/jdk/pull/21331 too.
> 
> I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.

@slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue.
I sent email to serviceability-dev because it is different from this PR.
https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html

Anyway, I'm waiting for Reviewers for this PR!

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3670212706

From ysuenaga at openjdk.org  Thu Dec 18 13:18:07 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 13:18:07 GMT
Subject: RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194 [v3]
In-Reply-To: <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
 <xJMT4VgrLAED9kIyDiogyANJEg5Ge_6c3-Qz7jkl69A=.a60f8a56-666f-4824-93ff-7172c7848930@github.com>
Message-ID: <XrpIwepgX6rrWOToO427dmU5MKpWo2QfSzh_znwg95s=.8ffc5c10-233c-44d5-bf1b-3488141318a9@github.com>

On Tue, 9 Dec 2025 01:08:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
>> 
>> This PR fixes it to implement `CFrame::toFrame`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check RBP

Thanks a lot for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28686#issuecomment-3670247042

From ysuenaga at openjdk.org  Thu Dec 18 13:18:08 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 13:18:08 GMT
Subject: Integrated: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
In-Reply-To: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
References: <CKBnDu8KOex_tdwMnL5HDXCKz-jb-sVtStsorSQqs4M=.6548f020-1d71-42cf-8a5a-0a13c39199a4@github.com>
Message-ID: <OLdfacJsEgi4xOp5OTAPaSMJ0Y1M7AbOSDfI8Dqdp74=.22f7a67d-5204-457b-9b6b-9993037fb376@github.com>

On Sat, 6 Dec 2025 02:35:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> [JDK-8371194](https://bugs.openjdk.org/browse/JDK-8371194) (PR #28284) has broken PStack (jstack --mixed) behavior on macOS. It affects both AMD64 and AArch64. See JBS for details.
> 
> This PR fixes it to implement `CFrame::toFrame`.

This pull request has now been integrated.

Changeset: b848ddf6
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f
Stats:     97 lines in 3 files changed: 68 ins; 3 del; 26 mod

8373110: jstack --mixed frames are broken on macOS after JDK-8371194

Reviewed-by: cjplummer, kevinw

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

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

From duke at openjdk.org  Thu Dec 18 13:39:59 2025
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 18 Dec 2025 13:39:59 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <Kwk3wW07aJGKj57Et4MJBUt1iLel0wHF_VtDVfp0_4k=.8b9963cb-ef2f-484f-ac36-61b37820fdc4@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>
 <Kwk3wW07aJGKj57Et4MJBUt1iLel0wHF_VtDVfp0_4k=.8b9963cb-ef2f-484f-ac36-61b37820fdc4@github.com>
Message-ID: <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com>

On Thu, 18 Dec 2025 13:06:58 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518). It's failing in some of Oracle's CI but I have not been able to reproduce the failure myself. It was discussed a bit in https://github.com/openjdk/jdk/pull/21331 too.
>> 
>> I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.
>
> @slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue.
> I sent email to serviceability-dev because it is different from this PR.
> https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html
> 
> Anyway, I'm waiting for Reviewers for this PR!

@YaSuenag Interesting, thanks for figuring that part out.

In any case, I also ran the tests locally now (using Docker 29.1.3 on Ubuntu 24.04), both on the latest JDK master branch and on your branch. Both passed.


make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=RUN_PROBLEM_LISTS=true


But on another note, I'm wondering if this change breaks the fix from https://bugs.openjdk.org/browse/JDK-8226919 and https://github.com/openjdk/jdk/pull/17628.

Unfortunately there is no jtreg test for it, but by following the steps I did in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081 and trying to attach to a JVM run as a systemd unit with extra privileges using a JDK built from this branch, I got this error:


[15:35:41] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
openjdk version "27-internal" 2026-09-15
OpenJDK Runtime Environment (build 27-internal-adhoc.slovdahl.jdk)
OpenJDK 64-Bit Server VM (build 27-internal-adhoc.slovdahl.jdk, mixed mode, sharing)

[15:30:58] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
2799281:
com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
        at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
        at java.base/java.nio.file.Files.isSameFile(Files.java:1418)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:275)
        ... 6 more


Before JDK-8226919 was fixed one got a timeout instead. Similar to the behaviour before JDK-8226919, using root when attaching works with a JDK built from this branch:


[15:32:20] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
2799281:
com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
        at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
        at java.base/java.nio.file.Files.isSameFile(Files.java:1418)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:275)
        ... 6 more


Are you able to replicate the same error locally?

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3670336288

From fbredberg at openjdk.org  Thu Dec 18 13:44:25 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 18 Dec 2025 13:44:25 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <xXJQCitavemKFXqiCfFTM20fDddUs-YqFNzPd0SgA9A=.e79a44e2-564a-406a-92a5-12c507bdb23e@github.com>

On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

This is a nice fix, regardless of my opinion about pre/post-decrement. Thank you David.

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

> 964:   void exit_critical() {
> 965:     assert(Thread::current() == this, "this must be current thread");
> 966:     if (_jni_active_critical-- == 1) {

Suggestion:

    if (--_jni_active_critical == 0) {

I know my suggested line really does the same as yours, but this way I feel it's easier to see that we re-enable suspension when the number of active critical regions are down to 0. I.e. I prefer pre-decrement and compare to 0, vs. post-decrement and compare to 1.

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

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28884#pullrequestreview-3593033724
PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2631125115

From ysuenaga at openjdk.org  Thu Dec 18 15:05:24 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 15:05:24 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory [v2]
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <SJiLOLCv12CgMbCqBJ84v1yUok1kWRdulBmrPqc_42I=.911ac3b7-3e45-4737-a620-70102cc44199@github.com>

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Check whether target process is on same host

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28867/files
  - new: https://git.openjdk.org/jdk/pull/28867/files/4b253b8b..fb1a16a3

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

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

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

From ysuenaga at openjdk.org  Thu Dec 18 15:08:18 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Dec 2025 15:08:18 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>
 <Kwk3wW07aJGKj57Et4MJBUt1iLel0wHF_VtDVfp0_4k=.8b9963cb-ef2f-484f-ac36-61b37820fdc4@github.com>
 <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com>
Message-ID: <4lAxeGWOgPOogPVnP91CrrxcZsAqVt8mMKIL85AghIA=.acda7403-2452-41b3-bb26-eb02c9755a87@github.com>

On Thu, 18 Dec 2025 13:37:50 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> @slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue.
>> I sent email to serviceability-dev because it is different from this PR.
>> https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html
>> 
>> Anyway, I'm waiting for Reviewers for this PR!
>
> @YaSuenag Interesting, thanks for figuring that part out.
> 
> In any case, I also ran the tests locally now (using Docker 29.1.3 on Ubuntu 24.04), both on the latest JDK master branch and on your branch. Both passed.
> 
> 
> make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=RUN_PROBLEM_LISTS=true
> 
> 
> But on another note, I'm wondering if this change breaks the fix from https://bugs.openjdk.org/browse/JDK-8226919 and https://github.com/openjdk/jdk/pull/17628.
> 
> Unfortunately there is no jtreg test for it, but by following the steps I did in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081 and trying to attach to a JVM run as a systemd unit with extra privileges using a JDK built from this branch, I got this error:
> 
> 
> [15:35:41] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
> openjdk version "27-internal" 2026-09-15
> OpenJDK Runtime Environment (build 27-internal-adhoc.slovdahl.jdk)
> OpenJDK 64-Bit Server VM (build 27-internal-adhoc.slovdahl.jdk, mixed mode, sharing)
> 
> [15:30:58] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
> 2799281:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp
>         at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
>         at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
>         at java.base...

@slovdahl 
I fixed. The latest commit checks target process and attacher on same host (situation that `jcmd` / `jps` shows target process). I believe it works fine on your environment - it works with your reproducer on my Fedora 43 at least. Could you check?

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

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3670757023

From lmesnik at openjdk.org  Thu Dec 18 16:13:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 16:13:44 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <W9jCUJskPov7QFvvatzWHGcLzQz6kQB832Nlv66moTQ=.ca39afdb-a9f4-42f4-9bde-4130bc3973ad@github.com>

On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

The fix looks good. 
Do you think it makes a sense to add regression test?

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28884#pullrequestreview-3593771798

From kustos at gmx.net  Thu Dec 18 16:29:36 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Thu, 18 Dec 2025 17:29:36 +0100
Subject: Test failure in TestJcmdWithSideCar.java
In-Reply-To: <9a2b8de506ccf43f00a9d37e1c94698f@oss.nttdata.com>
References: <9a2b8de506ccf43f00a9d37e1c94698f@oss.nttdata.com>
Message-ID: <d7d1e26d-9c3e-42ad-b53a-bbd537c62a1e@gmx.net>



On 12/18/25 14:04, Yasumasa Suenaga wrote:
> Hi,
> 
> I'm working on JDK-28867 ( https://github.com/openjdk/jdk/pull/28867 ), 
> and @slovdahl said this PR might fix the failure in 
> TestJcmdWithSideCar.java which has been recorded in ProblemList. 
> Unfortunately this PR fix that problem, but I found the cause of 
> failure, so I will tell it to the maillist.
> 
> The cause is mismatch container base image and OS of build host.
> 
> I'm using Fedora 43 to build OpenJDK, however container test would use 
> ubuntu:latest image by default.
> Thus I saw error in dynamic linker in .jtr file as following. It is why 
> main container wasn't started.
> 
> ```
> [main-container-process] Error: dl failure on line 532
> [main-container-process] Error: failed /jdk/lib/server/libjvm.so, 
> because /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_ABI_GNU2_TLS' 
> not found (required by /jdk/lib/server/libjvm.so)
> ```
> 
> The test passed when I added both -Djdk.test.docker.image.name - 
> Djdk.test.docker.image.version as following.
> 
> ```
> make test TEST=test/hotspot/jtreg/containers/docker/ 
> TestJcmdWithSideCar.java JTREG="JAVA_OPTIONS=- 
> Djdk.test.container.command=podman -Djdk.test.docker.image.name=fedora - 
> Djdk.test.docker.image.version=43"
> ```
> 
> 
> Thus it is an environment problem. Not a bug.

That test has quite a few issues. A somewhat related issue is that the 
working directory of the main container is / but this is not shared with 
the side car [1].

Then there are the issues that a lot of the test infrastructure relies 
on polling and timeouts rather than signals with makes the tests 
unnecessarily long. Ie. EventGeneratorLoop should add a shutdown hook 
and exit on interruption.

And yes, a lot of the comments in #findTargetProcessTmpDirectory do not 
make much sense when compared to the implementation. And to my knowledge 
we should test for execute rather than write permission on the temp dir 
as target process creates the socket file, not the attaching process.

  [1] https://github.com/openjdk/jdk/pull/26712#issuecomment-3508500130

Regards
Philippe

From cjplummer at openjdk.org  Thu Dec 18 17:08:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Dec 2025 17:08:24 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
 <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>
Message-ID: <pLY5S80MHBaMO-dxZZ-TviByW_eBH_VsNteySZWpflw=.bf699af4-259d-46f2-9496-ccd0677b9b8a@github.com>

On Thu, 18 Dec 2025 11:43:22 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

I know of no reason why SA won't work with JVMCI disabled, but I'm also not sure if we test that so there could be bugs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2631875749

From mablakatov at openjdk.org  Thu Dec 18 17:18:41 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 18 Dec 2025 17:18:41 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
Message-ID: <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>

On Thu, 18 Dec 2025 02:23:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

It might be possible to move both `CodeBlob` and `nmethod` data to the C-heap. We'd still need something like an `_hdr` pointer, since JVM resolves a `CodeBlob` from a method/stub entry point using  [`CodeBlob* CodeCache::find_blob(void* start)`](https://github.com/openjdk/jdk/blob/7a7e7c9ae11cb124c14d5d2d3b7e2f5649205106/src/hotspot/share/code/codeCache.cpp#L640). So if we move every member field to the C-heap, we store a pointer to that data right before a method/stub entry point in the CodeCache and that's it. A `_code` pointer pointing from the C-heap into the CodeCache may not be necessary at all.

That said, this would require moving data for other `CodeBlob` subclasses (`AdapterBlob`, `ExceptionBlob`, etc.) to the C-heap, which would significantly broaden the scope of this patch. 

@Bhavana-Kilambi , what do you thing? Is this something you've considered?

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

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3671287737

From pchilanomate at openjdk.org  Thu Dec 18 19:01:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Dec 2025 19:01:58 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
Message-ID: <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>

On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>  - Merge branch 'master' into 8369515-jni-critical
>  - Revert "8369515"
>    
>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>  - 8369515

Looks good to me.

FTR we are not processing this special exit condition when transitioning from `_thread_blocked` to `_thread_in_vm` already, so I would assume it should be also okay for any native->vm transition.

src/hotspot/share/runtime/javaThread.cpp line 1057:

> 1055:   // We mustn't block for object deopt if the thread is
> 1056:   // currently executing in a JNI critical region, as that
> 1057:   // can cause deadlock because the GCLocker is held.

I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"?

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3594584056
PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3671778255
PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2632288550

From pchilanomate at openjdk.org  Thu Dec 18 19:29:12 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Dec 2025 19:29:12 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>

On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3671897422

From duke at openjdk.org  Thu Dec 18 20:29:38 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 18 Dec 2025 20:29:38 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v2]
In-Reply-To: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. JVMTI events however are not guaranteed to be published before the JVM exits which can occasionally cause the test to fail. Instead of failing if the events are not receive the test was modified to print an error and pass. However, the test will still fail if the method fails to compile or if the nmethod fails to relocate.

Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:

 - Require load and unload events
 - Revert "Fix NMethodRelocationTest"
   
   This reverts commit dae91d8d12820c94c2c412f3e84935072e572595.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28683/files
  - new: https://git.openjdk.org/jdk/pull/28683/files/dae91d8d..d1577f8e

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

  Stats: 144 lines in 1 file changed: 64 ins; 67 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28683/head:pull/28683

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

From duke at openjdk.org  Thu Dec 18 20:38:05 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 18 Dec 2025 20:38:05 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v2]
In-Reply-To: <_QtxmNSHId9nv60mC3o5sIJ0ONiFiBTj61YDI59s7cs=.0e732d32-38da-4bfd-8b96-56d70ba747fe@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <_QtxmNSHId9nv60mC3o5sIJ0ONiFiBTj61YDI59s7cs=.0e732d32-38da-4bfd-8b96-56d70ba747fe@github.com>
Message-ID: <pvG3C7zj8zmOjsLi5VVZtirQpH9coz8Q4le3kT5rQpE=.f9e5d994-fe68-42b8-b067-b4b061ad7a67@github.com>

On Thu, 11 Dec 2025 06:35:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Require load and unload events
>>  - Revert "Fix NMethodRelocationTest"
>>    
>>    This reverts commit dae91d8d12820c94c2c412f3e84935072e572595.
>
> test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 172:
> 
>> 170:         WHITE_BOX.lockCompilation();
>> 171: 
>> 172:         System.out.printf("Relocated nmethod from 0x%016x to 0x%016x%n", originalNMethod.code_begin, relocatedNMethod.code_begin);
> 
> I think it is better to wait until method_unload is generated rather then don't check it in the test.
> If tests times out while waiting for jvmti event we could analyze process dumps and logs trying to understand while jvmti event hasn't been posted. 
> it might be sense to call WB.fullGC(), check if jvmti event posted sleep some time and repeat in the loop.

Thanks for the suggestion. I posted a new revision that requires the events be published.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2632547115

From cjplummer at openjdk.org  Thu Dec 18 20:45:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Dec 2025 20:45:25 GMT
Subject: RFR: 8374038: JDI EventRequestManager javadoc has unrendered @link
 tags inside an @code block
Message-ID: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>

Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.

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

Commit messages:
 - fix minor typo
 - fix minor typo
 - Remove @links from @code blocks

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

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

From dholmes at openjdk.org  Thu Dec 18 21:18:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 21:18:25 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <xXJQCitavemKFXqiCfFTM20fDddUs-YqFNzPd0SgA9A=.e79a44e2-564a-406a-92a5-12c507bdb23e@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <xXJQCitavemKFXqiCfFTM20fDddUs-YqFNzPd0SgA9A=.e79a44e2-564a-406a-92a5-12c507bdb23e@github.com>
Message-ID: <qIfNR6EbTtcSId5nq47yGlJZ3gV4Ym-qRAUwfm_rXVg=.ddc7bbab-12d1-4b72-a748-2d5d6cef51b3@github.com>

On Thu, 18 Dec 2025 13:32:53 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> src/hotspot/share/runtime/javaThread.hpp line 966:
> 
>> 964:   void exit_critical() {
>> 965:     assert(Thread::current() == this, "this must be current thread");
>> 966:     if (_jni_active_critical-- == 1) {
> 
> Suggestion:
> 
>     if (--_jni_active_critical == 0) {
> 
> I know my suggested line really does the same as yours, but this way I feel it's easier to see that we re-enable suspension when the number of active critical regions are down to 0. I.e. I prefer pre-decrement and compare to 0, vs. post-decrement and compare to 1.

I prefer to view the transitions on the current count as being zero and one, rather than the post-count being one and zero.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2632659327

From dholmes at openjdk.org  Thu Dec 18 21:29:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 21:29:53 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
Message-ID: <ht8fzn6qsdEGzMiIQp8CofS28xVxufmPwA3Ti9MHJVU=.c2c13b2f-25a8-4940-8f74-733d5a8f0845@github.com>

On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.

Thanks for looking at this @pchilano 

> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. 

This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else.

> We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.

So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672311790

From dholmes at openjdk.org  Thu Dec 18 21:29:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 21:29:55 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <W9jCUJskPov7QFvvatzWHGcLzQz6kQB832Nlv66moTQ=.ca39afdb-a9f4-42f4-9bde-4130bc3973ad@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <W9jCUJskPov7QFvvatzWHGcLzQz6kQB832Nlv66moTQ=.ca39afdb-a9f4-42f4-9bde-4130bc3973ad@github.com>
Message-ID: <ONDJ36EmjC-35f0xoppI3fIrx1KOMm5mVO2dXqsHFAw=.afb76c20-5960-4208-ac4a-11526b2d7947@github.com>

On Thu, 18 Dec 2025 16:10:54 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix looks good. Do you think it makes a sense to add regression test?

Thanks for looking at this @lmesnik . It would be nice to have a regression test for this but constructing one is beyond my ability to write JVM TI programs.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672320422

From dholmes at openjdk.org  Thu Dec 18 21:29:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 21:29:56 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <xXJQCitavemKFXqiCfFTM20fDddUs-YqFNzPd0SgA9A=.e79a44e2-564a-406a-92a5-12c507bdb23e@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <xXJQCitavemKFXqiCfFTM20fDddUs-YqFNzPd0SgA9A=.e79a44e2-564a-406a-92a5-12c507bdb23e@github.com>
Message-ID: <iCt_KVgcLItVZe-JAr8ELqyIX00VJ3EYpTZYrqfi-CM=.c6255548-aada-4e47-8262-25a2bea72155@github.com>

On Thu, 18 Dec 2025 13:41:21 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> This is a nice fix, regardless of my opinion about pre/post-decrement. Thank you David.

Thanks for looking at this @fbredber

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672324023

From cjplummer at openjdk.org  Thu Dec 18 23:07:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Dec 2025 23:07:53 GMT
Subject: RFR: 8374038: JDI EventRequestManager javadoc has unrendered @link
 tags inside an @code block [v2]
In-Reply-To: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
References: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
Message-ID: <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>

> Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.
> 
> Here's what the current version looks like before any fixes: https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/EventRequestManager.html#createStepRequest(com.sun.jdi.ThreadReference,int,int)

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

 - Merge branch 'master' into 8374038_ERM_javadoc
   Merge
 - fix minor typo
 - fix minor typo
 - Remove @links from @code blocks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28907/files
  - new: https://git.openjdk.org/jdk/pull/28907/files/50025553..bb214afc

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

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

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

From pchilanomate at openjdk.org  Thu Dec 18 23:27:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Dec 2025 23:27:53 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
Message-ID: <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>

On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.

> Thanks for looking at this @pchilano
> 
> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done.
> 
> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else.
> 
It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead.

> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
> 
> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition.
>
It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions).

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672704793

From dholmes at openjdk.org  Fri Dec 19 01:55:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Exapnd comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28779/files
  - new: https://git.openjdk.org/jdk/pull/28779/files/b96a9bc2..9bc8a3f8

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

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

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

From dholmes at openjdk.org  Fri Dec 19 01:55:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:32 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
 <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>
Message-ID: <pcrDW-Y9FJPJy2FR9BgaT-QVtyEFgYCJ8t7V9WZpLfE=.a46dfdca-4c46-414f-aad5-eed929aeeb10@github.com>

On Thu, 18 Dec 2025 09:20:06 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>>  - Merge branch 'master' into 8369515-jni-critical
>>  - Revert "8369515"
>>    
>>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>>  - 8369515
>
> Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you!

Thanks for the reviews @fbredber and @pchilano !

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3673102814

From dholmes at openjdk.org  Fri Dec 19 01:55:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:34 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
 <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>
Message-ID: <fcrk1s7T_5aT6o_bkal4CnU1dUODHD9aWYct5mtGdus=.c5d8daa8-3571-42aa-8e5c-48d17b299ee1@github.com>

On Thu, 18 Dec 2025 18:56:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>>  - Merge branch 'master' into 8369515-jni-critical
>>  - Revert "8369515"
>>    
>>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>>  - 8369515
>
> src/hotspot/share/runtime/javaThread.cpp line 1057:
> 
>> 1055:   // We mustn't block for object deopt if the thread is
>> 1056:   // currently executing in a JNI critical region, as that
>> 1057:   // can cause deadlock because the GCLocker is held.
> 
> I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"?

I have reworded and expanded the last part. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2633282213

From dholmes at openjdk.org  Fri Dec 19 02:11:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 02:11:56 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <AjbhO7374LbveWmMDWAqt7kQKIQGvoTM0PWNuPdgjbc=.90d5e284-f3d9-4c4f-9f36-e583845d2b07@github.com>

On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

FTR I don't think "returning a copy" is an option - as I tried to point out in the other JBS issue. It would have to be based on there being a debugger attached, but with dynamic attach for the debugger you'd have to wait for an existing critical region to complete when attaching. If we have to wait for something then probably better just to wait for the thread in the critical region that we are trying to suspend. But doing a busy-wait (`while (t->in_critical()) SpinYield()`) in `SuspendThreadHandshakeClosure` seems a bit hackish. I had hoped the "disable suspend" mechanism would be simple and elegant.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3673153689

From syan at openjdk.org  Fri Dec 19 02:43:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 02:43:37 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force
 GC and might cause GC in other threads
Message-ID: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>

Hi all,

This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.

Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.

Additional testing:

- [ ] All jtreg tests by fastdebug build

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

Commit messages:
 - Remove unnecessary unloadClass
 - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads

Changes: https://git.openjdk.org/jdk/pull/28891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373945
  Stats: 157 lines in 25 files changed: 73 ins; 54 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

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

From syan at openjdk.org  Fri Dec 19 02:43:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 02:43:37 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <c5B3Q9hmRL0tW0VgLPOPZ3clCu02MfS8boU4W9xUsXs=.fec0eeb6-2d4a-47f0-939f-626c9bf0f28b@github.com>

On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

GHA report jdk build fails on linux-x64-hs-optimized. Seems like environmental issue or infrastructure issue. It's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3669059576

From syan at openjdk.org  Fri Dec 19 03:25:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 03:25:34 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v2]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

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

 - Merge branch 'openjdk:master' into jbs8373945
 - Remove unnecessary unloadClass
 - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/999908ea..3028bbea

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

  Stats: 3116 lines in 74 files changed: 2082 ins; 635 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

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

From syan at openjdk.org  Fri Dec 19 03:52:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 03:52:51 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v2]
In-Reply-To: <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>
Message-ID: <dnE_ADJmmCWdsMM1eKzIyBS6hOJdy1MSdiNnVxUINE0=.8a8a0b48-085a-4dc4-892f-ee39f359828f@github.com>

On Fri, 19 Dec 2025 03:25:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8373945
>  - Remove unnecessary unloadClass
>  - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads

There are other 36 tests need to be updated since the change of `unloadClass`

[tests.txt](https://github.com/user-attachments/files/24250041/tests.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3673373828

From lmesnik at openjdk.org  Fri Dec 19 04:52:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 19 Dec 2025 04:52:04 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v2]
In-Reply-To: <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>
Message-ID: <Z0yLX9L4OibKe5nSw-hffuOXW5GOjNURu3GTpgPxZ4E=.162baabd-039a-4d74-8c3a-ffeb228918fb@github.com>

On Fri, 19 Dec 2025 03:25:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8373945
>  - Remove unnecessary unloadClass
>  - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads

Thank you for fixing this. It improves reliability of testing significantly. However more changes and testing is needed.
I started discussion inline to have it in thread.

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 36:

> 34: import nsk.share.test.ExecutionController;
> 35: import nsk.share.test.Stresser;
> 36: import jdk.test.whitebox.WhiteBox;

This change impacts a lot of tests in vmTestbase. They are going to be broken if are using classunloading.
Si it requires testing of ALL vmTestbase tests to ensure that all test are fixed, not only monitoring.

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

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3596794660
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2633597452

From dholmes at openjdk.org  Fri Dec 19 06:16:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 06:16:28 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

David Holmes has updated the pull request incrementally with two additional commits since the last revision:

 - Delay suspender whilst target is in-critical
 - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
   
   This reverts commit 7723275e4495cc1f514c531afe752210209617cc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28884/files
  - new: https://git.openjdk.org/jdk/pull/28884/files/7723275e..2df50e50

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

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

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

From dholmes at openjdk.org  Fri Dec 19 06:16:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 06:16:29 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
Message-ID: <d8o8qtDslMCmoDqfW9AsLs-FUUiWqW0aFxU3QhScR68=.3ee612fa-7634-4369-906b-d13c755e76f4@github.com>

On Thu, 18 Dec 2025 23:25:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
>
>> Thanks for looking at this @pchilano
>> 
>> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done.
>> 
>> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else.
>> 
> It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead.
> 
>> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
>> 
>> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition.
>>
> It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions).

@pchilano is the latest proposal more what you were thinking? It has an obvious flaw if the critical region is badly behaved, but perhaps we just live with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3673697095

From syan at openjdk.org  Fri Dec 19 06:17:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 06:17:53 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v2]
In-Reply-To: <Z0yLX9L4OibKe5nSw-hffuOXW5GOjNURu3GTpgPxZ4E=.162baabd-039a-4d74-8c3a-ffeb228918fb@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <cv1Zcvd3YH-mQdvR1XuF1fvWL15BjZozCe7URtl20B0=.b64d2cda-70a8-43aa-b6ed-dd60d302f8d1@github.com>
 <Z0yLX9L4OibKe5nSw-hffuOXW5GOjNURu3GTpgPxZ4E=.162baabd-039a-4d74-8c3a-ffeb228918fb@github.com>
Message-ID: <vkqpS9ZENZiVKbVY0OsvOa42OA_5R6F6FSvATwwAdKk=.faf5d39d-16a0-4b2a-8147-ffb9533977ec@github.com>

On Fri, 19 Dec 2025 04:48:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jbs8373945
>>  - Remove unnecessary unloadClass
>>  - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads
>
> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 36:
> 
>> 34: import nsk.share.test.ExecutionController;
>> 35: import nsk.share.test.Stresser;
>> 36: import jdk.test.whitebox.WhiteBox;
> 
> This change impacts a lot of tests in vmTestbase. They are going to be broken if are using classunloading.
> Si it requires testing of ALL vmTestbase tests to ensure that all test are fixed, not only monitoring.

Thanks. I am also noticed that some other test need to be updated after the change of classunloading.

I will do it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2633807610

From jbhateja at openjdk.org  Fri Dec 19 06:29:57 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 19 Dec 2025 06:29:57 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
Message-ID: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>

On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>
>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
> 
> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments.
Hi @eme64 , Kindly share your comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673727967

From syan at openjdk.org  Fri Dec 19 06:43:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 06:43:36 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v3]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <DpKNuQjx7_01t6mYuPRr8kNIDgqY2AW8pmc0PPJX4w8=.6f6ee917-33cd-409b-91cb-22c4161a3878@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

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

  Update test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects 5 tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/3028bbea..7e67804f

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

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

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

From duke at openjdk.org  Fri Dec 19 06:45:53 2025
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Fri, 19 Dec 2025 06:45:53 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory [v2]
In-Reply-To: <SJiLOLCv12CgMbCqBJ84v1yUok1kWRdulBmrPqc_42I=.911ac3b7-3e45-4737-a620-70102cc44199@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <SJiLOLCv12CgMbCqBJ84v1yUok1kWRdulBmrPqc_42I=.911ac3b7-3e45-4737-a620-70102cc44199@github.com>
Message-ID: <ti8x2P6rSHepbmfUbRGSMMMLdFrwHOP2VJjhrQRj6j0=.9e061835-d95a-4738-a9a8-5214a793b278@github.com>

On Thu, 18 Dec 2025 15:05:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check whether target process is on same host

Curious how it works on your Fedora 43, I'm still seeing the same error.


[08:40:27] ~/d/e/jdk ? pull/28867 ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
52779:
com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:292)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:233)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:84)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Caused by: java.nio.file.AccessDeniedException: /proc/52779/root/tmp
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
        at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
        at java.base/java.nio.file.Files.isSameFile(Files.java:1418)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:277)
        ... 6 more


It's the `Files.isSameFile(tmpOnProcPidRoot, TMPDIR)` check that throws `java.nio.file.AccessDeniedException`, so the `MonitoredHost.getMonitoredHost` check seems to come too late?

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 293:

> 291:         } catch (Exception e) {
> 292:             throw new AttachNotSupportedException("Unable to access the filesystem of the target process", e);
> 293:         }

Not sure if this stays like it is, but if it does, we can probably avoid wrapping `AttachNotSupportedException`:

Suggestion:

        } catch (AttachNotSupportedException e) {
            throw e;
        } catch (Exception e) {
            throw new AttachNotSupportedException("Unable to access the filesystem of the target process", e);
        }

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

PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3597133147
PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2633882957

From epeter at openjdk.org  Fri Dec 19 07:03:58 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 19 Dec 2025 07:03:58 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
 <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
Message-ID: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com>

On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>>> 
>>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>> 
>> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.
>
> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments.
> Hi @eme64 , Kindly share your comments.

@jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :)

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673842243

From syan at openjdk.org  Fri Dec 19 08:36:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 08:36:46 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v4]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <EdAQiOYb1WPlFPvUMaQa9BySg-f7pkphVjy-olbsBV8=.32277461-69e2-460c-9aa6-a542a8ff1ddc@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

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

  Fix other tests except CompiledMethodUnload/compmethunload001/TestDescription.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/7e67804f..47c508a5

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

  Stats: 178 lines in 31 files changed: 92 ins; 29 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

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

From syan at openjdk.org  Fri Dec 19 08:45:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 08:45:37 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

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

  Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/47c508a5..c752a052

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

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

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

From rrich at openjdk.org  Fri Dec 19 09:57:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Dec 2025 09:57:40 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

I wonder why there are no GHA tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674358347

From pchilanomate at openjdk.org  Fri Dec 19 11:22:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Dec 2025 11:22:33 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
Message-ID: <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>

On Thu, 18 Dec 2025 23:25:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
>
>> Thanks for looking at this @pchilano
>> 
>> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done.
>> 
>> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else.
>> 
> It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead.
> 
>> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
>> 
>> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition.
>>
> It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions).

> @pchilano is the latest proposal more what you were thinking? It has an obvious flaw if the critical region is badly behaved, but perhaps we just live with that.
>
Thanks David. I was thinking on having a `in_critical()` check in `HandshakeState::try_process` when the op returned by `get_op()` is `SuspendThreadHandshakeClosure` since we already have the `HandshakeSpinYield` of the operation. This avoids spinning in the closure which would block other handshakes or safepoints. And if the check fails we could pick another operation, if available, and not just return `_not_safe` to retry (to avoid stalling other handshakes once the suspend is at the front of the queue). But I guess it depends on how paranoid we are that this JNI API is being used correctly, so your simpler change could work too.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3674677513

From pchilanomate at openjdk.org  Fri Dec 19 11:22:37 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Dec 2025 11:22:37 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
Message-ID: <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>

On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Delay suspender whilst target is in-critical
>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>    
>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.

src/hotspot/share/runtime/suspendResumeManager.cpp line 64:

> 62:   }
> 63:   void do_thread(Thread* thr) {
> 64:     assert(thr != Thread::current(), "must be");

I think the target can execute this operation.

src/hotspot/share/runtime/suspendResumeManager.cpp line 70:

> 68:     // hang here. There is no way to time-out and abort the suspend request because
> 69:     // the API does not allow for that - if a thread is live then it can be suspended.
> 70:     if (target->in_critical_atomic()) {

I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634756340
PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634771987

From kevinw at openjdk.org  Fri Dec 19 11:25:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Dec 2025 11:25:08 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
Message-ID: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>

In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.

20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
Limiting to 5 iterations.

This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.

Tests that do some allocation and check for a collection can be unreliable.
This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891

I'd like to get this change in though, as the test may fail more now than before.

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

Commit messages:
 - limit iterations
 - JDK-8373642: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java failed

Changes: https://git.openjdk.org/jdk/pull/28923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373642
  Stats: 23 lines in 5 files changed: 7 ins; 5 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28923/head:pull/28923

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

From pchilanomate at openjdk.org  Fri Dec 19 11:46:41 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Dec 2025 11:46:41 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
Message-ID: <VHXzqFC5chVgdasYWcB94owKfd4eJCJg0CqGjpPFex0=.fdb929ab-6f91-4794-b1af-37ea09f4fee3@github.com>

On Fri, 19 Dec 2025 11:19:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Delay suspender whilst target is in-critical
>>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>>    
>>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 70:
> 
>> 68:     // hang here. There is no way to time-out and abort the suspend request because
>> 69:     // the API does not allow for that - if a thread is live then it can be suspended.
>> 70:     if (target->in_critical_atomic()) {
> 
> I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread.

And if there is a safepoint in these transitions I realized we would deadlock because this thread will never be safepoint safe. So maybe better to move the spinning out as I suggested above?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634832937

From kevinw at openjdk.org  Fri Dec 19 12:00:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Dec 2025 12:00:08 GMT
Subject: RFR: 8374038: JDI EventRequestManager javadoc has unrendered @link
 tags inside an @code block [v2]
In-Reply-To: <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
References: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
 <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
Message-ID: <xevEfhfwFoaTtl51qZM6nJ5IQWA-Oj-3CbDLZ_U0698=.8f4c2c4c-c956-4cd2-86a4-edddf12538e0@github.com>

On Thu, 18 Dec 2025 23:07:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.
>> 
>> Here's what the current version looks like before any fixes: https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/EventRequestManager.html#createStepRequest(com.sun.jdi.ThreadReference,int,int)
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8374038_ERM_javadoc
>    Merge
>  - fix minor typo
>  - fix minor typo
>  - Remove @links from @code blocks

Yes, what we have currently is clearly a mistake, good to tidy it up.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28907#pullrequestreview-3598335558

From dholmes at openjdk.org  Fri Dec 19 12:43:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 12:43:13 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
 <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>
Message-ID: <6vFGKEFch604SQW5BCHD9DhoUeYGKKVBjvN8Q9ByPQ0=.605967f2-e2ed-497c-907e-55b85be2d3cb@github.com>

On Fri, 19 Dec 2025 09:54:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I wonder why there are no GHA tests?

I don't run GHA by default.

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

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674939902

From dholmes at openjdk.org  Fri Dec 19 12:49:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 12:49:01 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
Message-ID: <aorOX5VxgWnSNKdf6eD1TsiUjFxMhiZ5fWx3i2-AB1M=.743b0604-1668-472f-b1d2-7405057b1c1a@github.com>

On Fri, 19 Dec 2025 11:13:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Delay suspender whilst target is in-critical
>>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>>    
>>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 64:
> 
>> 62:   }
>> 63:   void do_thread(Thread* thr) {
>> 64:     assert(thr != Thread::current(), "must be");
> 
> I think the target can execute this operation.

We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634990833

From dholmes at openjdk.org  Fri Dec 19 12:53:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 12:53:12 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <aorOX5VxgWnSNKdf6eD1TsiUjFxMhiZ5fWx3i2-AB1M=.743b0604-1668-472f-b1d2-7405057b1c1a@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
 <aorOX5VxgWnSNKdf6eD1TsiUjFxMhiZ5fWx3i2-AB1M=.743b0604-1668-472f-b1d2-7405057b1c1a@github.com>
Message-ID: <sHM1l2xik1lcxZNauIXiyp27dE4nwlV_HjGIv1UhzEU=.b1ff04d3-1add-4858-a7db-9413b6f9d550@github.com>

On Fri, 19 Dec 2025 12:45:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 64:
>> 
>>> 62:   }
>>> 63:   void do_thread(Thread* thr) {
>>> 64:     assert(thr != Thread::current(), "must be");
>> 
>> I think the target can execute this operation.
>
> We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this.

But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual `do_thread` operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635003209

From dholmes at openjdk.org  Fri Dec 19 13:02:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 13:02:28 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
 <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>
Message-ID: <Oou2S193-bghY6YdrKxHW_h9T7SduMlSOpLtCq6uKk4=.3c3febc0-1a89-41c9-b113-0585cfe44d88@github.com>

On Fri, 19 Dec 2025 11:18:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I was thinking on having a in_critical() check in HandshakeState::try_process when the op returned by get_op() is `SuspendThreadHandshakeClosure`

Checking the generic handshake code for a specific handshake operation seems like a horrendous hack - that code should never have to specialize based on the operation. The operation should handle any special cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3674993065

From dholmes at openjdk.org  Fri Dec 19 13:02:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 13:02:30 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <VHXzqFC5chVgdasYWcB94owKfd4eJCJg0CqGjpPFex0=.fdb929ab-6f91-4794-b1af-37ea09f4fee3@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
 <VHXzqFC5chVgdasYWcB94owKfd4eJCJg0CqGjpPFex0=.fdb929ab-6f91-4794-b1af-37ea09f4fee3@github.com>
Message-ID: <sHEdDMy9kDj32Q57-do-ujYG1MPYyyluNDGXnNZwxCA=.6cc142a0-2171-4053-a80a-2e9f82a5fea6@github.com>

On Fri, 19 Dec 2025 11:43:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 70:
>> 
>>> 68:     // hang here. There is no way to time-out and abort the suspend request because
>>> 69:     // the API does not allow for that - if a thread is live then it can be suspended.
>>> 70:     if (target->in_critical_atomic()) {
>> 
>> I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread.
>
> And if there is a safepoint in these transitions I realized we would deadlock because this thread will never be safepoint safe. So maybe better to move the spinning out as I suggested above?

Yeah I need to re-think this whole approach. What a mess. Thanks. :(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635022382

From pchilanomate at openjdk.org  Fri Dec 19 13:23:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Dec 2025 13:23:19 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <Oou2S193-bghY6YdrKxHW_h9T7SduMlSOpLtCq6uKk4=.3c3febc0-1a89-41c9-b113-0585cfe44d88@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
 <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>
 <Oou2S193-bghY6YdrKxHW_h9T7SduMlSOpLtCq6uKk4=.3c3febc0-1a89-41c9-b113-0585cfe44d88@github.com>
Message-ID: <Xeg9vmuxuvZmQs2Gdr4kG4BAt1Ngexa0bgpAIMLaaIQ=.902c07e5-919d-4982-8e63-3d1e76908dc5@github.com>

On Fri, 19 Dec 2025 12:59:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I was thinking on having a in_critical() check in HandshakeState::try_process when the op returned by get_op() is `SuspendThreadHandshakeClosure`
> 
> Checking the generic handshake code for a specific handshake operation seems like a horrendous hack - that code should never have to specialize based on the operation. The operation should handle any special cases.
>
We don't need to check for a specific operation, we can make it general by defining a virtual method in `HandshakeClosure` (e.g. `needs_jni_critical_check`) that's overriden by any operation that requires this check.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3675063379

From pchilanomate at openjdk.org  Fri Dec 19 13:23:20 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Dec 2025 13:23:20 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <sHM1l2xik1lcxZNauIXiyp27dE4nwlV_HjGIv1UhzEU=.b1ff04d3-1add-4858-a7db-9413b6f9d550@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <YLy4BsG9CZQuut04ucwEFlR8sfpNzMunW-HhhdBErj0=.7cc8ea09-5528-46e7-ac19-f881bd73ad0a@github.com>
 <aorOX5VxgWnSNKdf6eD1TsiUjFxMhiZ5fWx3i2-AB1M=.743b0604-1668-472f-b1d2-7405057b1c1a@github.com>
 <sHM1l2xik1lcxZNauIXiyp27dE4nwlV_HjGIv1UhzEU=.b1ff04d3-1add-4858-a7db-9413b6f9d550@github.com>
Message-ID: <LmzCko4fH14iKS3jv2qh_KF5OV2unaSH0mwLIETHVyk=.3dd9975a-413e-4cb3-884d-880bb0ac5465@github.com>

On Fri, 19 Dec 2025 12:50:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this.
>
> But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual `do_thread` operation.

> We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this.
>
Right, but that's only if the thread requested to suspend itself, not when the request is from a different thread.

> But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual do_thread operation.
>
Except for async hanshakes, a hanshake could be executed by either one. Even from another thread trying to handshake the same target.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635080415

From rrich at openjdk.org  Fri Dec 19 13:52:18 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Dec 2025 13:52:18 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <1NnXP_p6_XPsKO0kPmmColRPJZBTmtcl9x0TdRAPjfI=.e4920b21-6c57-455e-89cb-59456a9da863@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

Looks good.
Thanks, Richard.

A deadlock can still occur if the debugger suspends the thread in the critical region, e.g. to read a local variable. After [JDK-8373839](https://bugs.openjdk.org/browse/JDK-8373839) this shouldn't be possible anymore.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3598687723
PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3675155037

From ysuenaga at openjdk.org  Fri Dec 19 14:09:52 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 19 Dec 2025 14:09:52 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory [v3]
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <G36jPNI5AfN7GqVHAUfaCGAlbfoMZr78dgf6mFkiUBs=.2769cf0c-2399-4010-8fb2-c2af7695212d@github.com>

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix and add testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28867/files
  - new: https://git.openjdk.org/jdk/pull/28867/files/fb1a16a3..dfd9a18b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=01-02

  Stats: 117 lines in 2 files changed: 115 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28867/head:pull/28867

PR: https://git.openjdk.org/jdk/pull/28867

From ysuenaga at openjdk.org  Fri Dec 19 14:14:59 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 19 Dec 2025 14:14:59 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory
In-Reply-To: <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <UpKhtbY74_0g7noOJgLpzSuK0DIBA2CPlc4nVJZyOR8=.3d499577-ae91-46e1-bc29-ed80ecd5291b@github.com>
 <Kwk3wW07aJGKj57Et4MJBUt1iLel0wHF_VtDVfp0_4k=.8b9963cb-ef2f-484f-ac36-61b37820fdc4@github.com>
 <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com>
Message-ID: <mzBHD6Rr3lkiC15JJkCHGSshnPVi2m4-B91333TLEy8=.0cd6b2c1-e2c4-41cc-9359-47dc5d21fb0d@github.com>

On Thu, 18 Dec 2025 13:37:50 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> @slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue.
>> I sent email to serviceability-dev because it is different from this PR.
>> https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html
>> 
>> Anyway, I'm waiting for Reviewers for this PR!
>
> @YaSuenag Interesting, thanks for figuring that part out.
> 
> In any case, I also ran the tests locally now (using Docker 29.1.3 on Ubuntu 24.04), both on the latest JDK master branch and on your branch. Both passed.
> 
> 
> make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=RUN_PROBLEM_LISTS=true
> 
> 
> But on another note, I'm wondering if this change breaks the fix from https://bugs.openjdk.org/browse/JDK-8226919 and https://github.com/openjdk/jdk/pull/17628.
> 
> Unfortunately there is no jtreg test for it, but by following the steps I did in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081 and trying to attach to a JVM run as a systemd unit with extra privileges using a JDK built from this branch, I got this error:
> 
> 
> [15:35:41] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
> openjdk version "27-internal" 2026-09-15
> OpenJDK Runtime Environment (build 27-internal-adhoc.slovdahl.jdk)
> OpenJDK 64-Bit Server VM (build 27-internal-adhoc.slovdahl.jdk, mixed mode, sharing)
> 
> [15:30:58] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
> 2799281:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp
>         at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
>         at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
>         at java.base...

@slovdahl 
I fix the problem, and I added new testcase as TestWithoutDumpableProcess.java which covers your use case.
I reproduce the problem which is same situation with your case with `prctl()` with `PR_SET_DUMPABLE`. if `PR_SET_DUMPABLE` is disabled, most of file owner in procfs is root and we cannot access /proc/<PID>/root even though `jcmd` lists the process. New testcase call `prctl` via FFM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3675225882

From ysuenaga at openjdk.org  Fri Dec 19 14:47:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 19 Dec 2025 14:47:40 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory [v4]
In-Reply-To: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Improve exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28867/files
  - new: https://git.openjdk.org/jdk/pull/28867/files/dfd9a18b..3341dd60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28867/head:pull/28867

PR: https://git.openjdk.org/jdk/pull/28867

From cjplummer at openjdk.org  Fri Dec 19 18:46:02 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Dec 2025 18:46:02 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
Message-ID: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>

On Fri, 19 Dec 2025 08:45:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java

There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating.  There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments.

I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader.

test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:

> 152: 
> 153:                     // Drop all references to the class and try to unload it
> 154:                     WhiteBox.getWhiteBox().fullGC();

Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71:

> 69:  *      -transport.address=dynamic
> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
> 71:  *      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin

In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:

> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
> 49: 
> 50:     private final static int MAX_ITERATIONS = 50;

Can you explain the need for this change.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3599556766
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635960204
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635889453
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635893925

From psandoz at openjdk.org  Fri Dec 19 22:52:56 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 19 Dec 2025 22:52:56 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
 <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
Message-ID: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com>

On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>>> 
>>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>> 
>> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.
>
> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments.
> Hi @eme64 , Kindly share your comments.

> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :)

Same here!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3676923873

From amenkov at openjdk.org  Sat Dec 20 00:20:01 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 20 Dec 2025 00:20:01 GMT
Subject: RFR: 8374038: JDI EventRequestManager javadoc has unrendered @link
 tags inside an @code block [v2]
In-Reply-To: <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
References: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
 <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
Message-ID: <u0yp_VPPBXBMP9iLnQ_8VYRnx8iKxhHgGxKrI3T81Fg=.9238140a-47d2-47dc-9c31-6222ae221c1e@github.com>

On Thu, 18 Dec 2025 23:07:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.
>> 
>> Here's what the current version looks like before any fixes: https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/EventRequestManager.html#createStepRequest(com.sun.jdi.ThreadReference,int,int)
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8374038_ERM_javadoc
>    Merge
>  - fix minor typo
>  - fix minor typo
>  - Remove @links from @code blocks

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28907#pullrequestreview-3600498620

From syan at openjdk.org  Sat Dec 20 02:15:31 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 02:15:31 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v6]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <OCX3rot-UiotkIs2Ec_S-n3toO41GcQ4nC_MvPg1Tzg=.7846e340-66ee-4364-af0e-0b6e18f9f569@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Add indent for jdi tests in debugee.vmkeys line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/c752a052..5de8cc8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=04-05

  Stats: 26 lines in 25 files changed: 1 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Sat Dec 20 02:15:32 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 02:15:32 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <EqCUPuNRgVnrBxBZ4JMv6hKmOIdaes2t9h1fod0aI5k=.033174b1-591d-40c6-af32-f9d1d47227fe@github.com>

On Fri, 19 Dec 2025 18:08:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71:
> 
>> 69:  *      -transport.address=dynamic
>> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
>> 71:  *      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin
> 
> In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before.

Thanks. The indent has been added for jni tests

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636700458

From amenkov at openjdk.org  Sat Dec 20 02:16:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 20 Dec 2025 02:16:53 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent
Message-ID: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>

The fix resolves disabled warnings in debugger agent

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/28937/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374168
  Stats: 54 lines in 10 files changed: 18 ins; 32 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From cjplummer at openjdk.org  Sat Dec 20 02:46:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 20 Dec 2025 02:46:52 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <9lmjHGrV6x6050WJNE1iF1DuDY2CN-slOW0Hm0LtJi0=.eb972bb0-e781-4740-9817-b74bd66d1c82@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 980:

> 978: {
> 979:     // PlatformThreadsFilter contains nothing useful
> 980:     //PlatformThreadsFilter *filter = &FILTER(node, index).u.PlatformThreadsOnly;

I think you can just delete this.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2678:

> 2676:     if (error != JVMTI_ERROR_NONE) {
> 2677:         EXIT_ERROR(error, "cannot get current thread");
> 2678:     }

I'm not sure about his one since it is a behavior change. For example, we have:

    jthread thread = threadControl_currentThread();
    if ((thread != NULL) && (!threadControl_isDebugThread(thread))) {
        threadControl_setPendingInterrupt(thread);
    }

src/jdk.jdwp.agent/share/native/libjdwp/util.h line 64:

> 62: /* To handle "format string is not a string literal" warning. */
> 63: #if !defined(_MSC_VER)
> 64:   #define ATTRIBUTE_PRINTF(fmt, vargs)  __attribute__((format(printf, fmt, vargs)))

Why not ATTRIBUTE_FORMAT?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2636723706
PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2636726418
PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2636726766

From syan at openjdk.org  Sat Dec 20 04:43:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:43:08 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v7]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <y_aGNrlNy13FM1p8Pq2_XZi9IL0_YGkslSO2PWGzngg=.dc1f7c2a-b100-46d5-9daa-eecbce3c163e@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update the comments for gc/gctests/LargeObjects/large001/large001.java related tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/5de8cc8c..a5eaf607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05-06

  Stats: 25 lines in 5 files changed: 17 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Sat Dec 20 04:50:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:50:54 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>

On Fri, 19 Dec 2025 18:41:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:
> 
>> 152: 
>> 153:                     // Drop all references to the class and try to unload it
>> 154:                     WhiteBox.getWhiteBox().fullGC();
> 
> Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.

It seems that, the references is non null at the first time. So it will not unload the classes actually,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636777045

From syan at openjdk.org  Sat Dec 20 04:59:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:59:07 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update comments about "using memory stressing techique"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/a5eaf607..567c7623

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Sat Dec 20 04:59:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:59:09 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>

On Fri, 19 Dec 2025 18:42:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments.
> 
> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader.

The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3677383218

From duke at openjdk.org  Sat Dec 20 12:34:50 2025
From: duke at openjdk.org (khanbilal732)
Date: Sat, 20 Dec 2025 12:34:50 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <YhAtU_kxfv6TLmwOsfr3hVzfPNuFMbzhmSLoel69MIs=.ee51fdbd-4a13-4272-b896-68d11c275e29@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3601086687

From duke at openjdk.org  Sat Dec 20 12:38:51 2025
From: duke at openjdk.org (khanbilal732)
Date: Sat, 20 Dec 2025 12:38:51 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <z8ZJcRjZI0RMPjXSMAd8OjUP-okZJUn1Qs3siai05_M=.243df138-a563-49e3-9d40-b0a51cacde10@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3601088664

From nbenalla at openjdk.org  Sun Dec 21 14:31:46 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 21 Dec 2025 14:31:46 GMT
Subject: RFR: 8374177: Update @since of HotSpotAOTCacheMXBean after JDK-8373607
Message-ID: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>

Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

-------------

Depends on: https://git.openjdk.org/jdk/pull/28942

Commit messages:
 - update HotSpotAOTCacheMXBean `@since`

Changes: https://git.openjdk.org/jdk/pull/28944/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374177
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28944/head:pull/28944

PR: https://git.openjdk.org/jdk/pull/28944

From alanb at openjdk.org  Sun Dec 21 19:02:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Dec 2025 19:02:50 GMT
Subject: RFR: 8374177: Update @since of HotSpotAOTCacheMXBean after
 JDK-8373607
In-Reply-To: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
References: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
Message-ID: <gScCqxccwJ5JusA1rTZBh6ZgfH482F-POesMZbTDQX8=.e1239711-644e-4608-b785-aae411d0faa7@github.com>

On Sun, 21 Dec 2025 14:05:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28944#pullrequestreview-3601910722

From duke at openjdk.org  Sun Dec 21 19:24:03 2025
From: duke at openjdk.org (khanbilal732)
Date: Sun, 21 Dec 2025 19:24:03 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <cNsGUIvPue_WSgUtF2elMsNh1CD2FiRNuLinwQ1btD4=.50fa31d9-47a5-4626-908a-766c880e7f4a@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3601919023

From dholmes at openjdk.org  Mon Dec 22 01:30:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:30:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <1wh7XkntsNC-F398ebv89gGlyYSZC58blKrA-oRqb8c=.54dfaa49-e5fa-4193-b276-6784cd9b47c9@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3679915216

From dholmes at openjdk.org  Mon Dec 22 01:30:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:30:30 GMT
Subject: Integrated: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <JuSyw5LOTWtpBn777i-27UO_ae0TP5H9tOG6ULDBUTc=.fcb1dc75-3c77-4b15-9e05-92b0dd33be8d@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

This pull request has now been integrated.

Changeset: 25e87144
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25e87144c20fcf5aca99b92f061a0051096c2605
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: rrich, fbredberg, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/28779

From dholmes at openjdk.org  Mon Dec 22 01:34:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:34:55 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <Xeg9vmuxuvZmQs2Gdr4kG4BAt1Ngexa0bgpAIMLaaIQ=.902c07e5-919d-4982-8e63-3d1e76908dc5@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
 <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>
 <Oou2S193-bghY6YdrKxHW_h9T7SduMlSOpLtCq6uKk4=.3c3febc0-1a89-41c9-b113-0585cfe44d88@github.com>
 <Xeg9vmuxuvZmQs2Gdr4kG4BAt1Ngexa0bgpAIMLaaIQ=.902c07e5-919d-4982-8e63-3d1e76908dc5@github.com>
Message-ID: <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com>

On Fri, 19 Dec 2025 13:19:22 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> We don't need to check for a specific operation, we can make it general by defining a virtual method in `HandshakeClosure` (e.g. `needs_jni_critical_check`) that's overriden by any operation that requires this check.

That isn't really any better to me. The general purpose handshake code should not have to be JNI-critical aware.

That aside I'm also struggling to see how we make the originator thread block when the target thread executes the handshake operation code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3679933261

From cjplummer at openjdk.org  Mon Dec 22 03:20:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 03:20:01 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
Message-ID: <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>

On Sat, 20 Dec 2025 04:47:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:
>> 
>>> 152: 
>>> 153:                     // Drop all references to the class and try to unload it
>>> 154:                     WhiteBox.getWhiteBox().fullGC();
>> 
>> Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.
>
> It seems that, the references is non null at the first time. So it will not unload the classes actually,

I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638494890

From cjplummer at openjdk.org  Mon Dec 22 03:20:04 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 03:20:04 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
Message-ID: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>

On Sat, 20 Dec 2025 04:59:07 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments about "using memory stressing techique"

test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52:

> 50:  *     The test loads the classes with nsk.share.gc.GCClassUnloader class that
> 51:  *     extends nsk.share. *     The test loads the classes with nsk.share.gc.GCClassUnloader class.
> 52:  *     As soon as a class is loaded, the test creates an instance of

There seems to have been a copy-n-paste error here, and it was replicated in a few test  cases below.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71:

> 69:  *      -transport.address=dynamic
> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
> 71:  *                      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin

I think ./bin should be moved to a newline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638499254
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638506867

From syan at openjdk.org  Mon Dec 22 06:17:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 06:17:56 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
 <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
Message-ID: <PMgLqFCbe7xf7VQxMi4M_K41EYlnJ9eH6VDYjYkB8y8=.cd1b8144-e4f8-4406-bad4-d4049037b20e@github.com>

On Mon, 22 Dec 2025 03:12:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments about "using memory stressing techique"
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52:
> 
>> 50:  *     The test loads the classes with nsk.share.gc.GCClassUnloader class that
>> 51:  *     extends nsk.share. *     The test loads the classes with nsk.share.gc.GCClassUnloader class.
>> 52:  *     As soon as a class is loaded, the test creates an instance of
> 
> There seems to have been a copy-n-paste error here, and it was replicated in a few test  cases below.

Sorry... Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638795405

From syan at openjdk.org  Mon Dec 22 06:41:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 06:41:53 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
 <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
Message-ID: <gtjx7gozkbNfujBY24gHMCBz5s6tHRl_9vg84sqRrS4=.b2c4c92f-b52e-4f69-84d4-580466d6a206@github.com>

On Mon, 22 Dec 2025 03:16:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments about "using memory stressing techique"
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71:
> 
>> 69:  *      -transport.address=dynamic
>> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
>> 71:  *                      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin
> 
> I think ./bin should be moved to a newline.

Fixed for all the releated tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638834843

From syan at openjdk.org  Mon Dec 22 07:20:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 07:20:07 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>

On Fri, 19 Dec 2025 18:11:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:
> 
>> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>> 49: 
>> 50:     private final static int MAX_ITERATIONS = 50;
> 
> Can you explain the need for this change.

Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.

After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time.


Number of unloaded events 12 number of iterations 25
Number of unloaded events 1 number of iterations 36
Number of unloaded events 4 number of iterations 30


Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.

This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638907204

From duke at openjdk.org  Mon Dec 22 07:20:56 2025
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 22 Dec 2025 07:20:56 GMT
Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp
 directory [v4]
In-Reply-To: <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
Message-ID: <Pjds-lq6gmP38O4XIZKD7erkq7ZFDXpLQtRfdVuA_uQ=.996a3273-7e89-4adc-af05-5fcccfdacdc9@github.com>

On Fri, 19 Dec 2025 14:47:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve exception

Thank you @YaSuenag, works locally for me now too. Awesome to get a test added for it as well!

My approval is only cosmetic, but this is a great improvement nevertheless.

-------------

Marked as reviewed by slovdahl at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3602932327

From syan at openjdk.org  Mon Dec 22 08:46:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 08:46:55 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
Message-ID: <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>

On Mon, 22 Dec 2025 07:16:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:
>> 
>>> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>>> 49: 
>>> 50:     private final static int MAX_ITERATIONS = 50;
>> 
>> Can you explain the need for this change.
>
> Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.
> 
> After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time.
> 
> 
> Number of unloaded events 12 number of iterations 25
> Number of unloaded events 1 number of iterations 36
> Number of unloaded events 4 number of iterations 30
> 
> 
> Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.
> 
> This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change.

Another solution is make some sleep after call `unloadClass()`


diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
index 13058ec7864..15120d3cad6 100644
--- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
+++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
@@ -47,7 +47,7 @@ public class compmethunload001 {
     private final static String CLS_TO_BE_UNLOADED =
         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
 
-    private final static int MAX_ITERATIONS = 50;
+    private final static int MAX_ITERATIONS = 5;
 
     static {
         try {
@@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
 
         boolean clsUnloaded = clsUnLoader.unloadClass();
         clsUnLoader = null;
+        Thread.sleep(5000);
         System.gc();
     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2639101290

From bkilambi at openjdk.org  Mon Dec 22 15:20:11 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 22 Dec 2025 15:20:11 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
 <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
Message-ID: <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>

On Thu, 18 Dec 2025 17:15:35 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> > Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.
> 
> It might be possible to move both `CodeBlob` and `nmethod` data to the C-heap. We'd still need something like an `_hdr` pointer, since JVM resolves a `CodeBlob` from a method/stub entry point using [`CodeBlob* CodeCache::find_blob(void* start)`](https://github.com/openjdk/jdk/blob/7a7e7c9ae11cb124c14d5d2d3b7e2f5649205106/src/hotspot/share/code/codeCache.cpp#L640). So if we move every member field to the C-heap, we store a pointer to that data right before a method/stub entry point in the CodeCache and that's it. A `_code` pointer pointing from the C-heap into the CodeCache may not be necessary at all.
> 
> That said, this would require moving data for other `CodeBlob` subclasses (`AdapterBlob`, `ExceptionBlob`, etc.) to the C-heap, which would significantly broaden the scope of this patch.
> 
> @Bhavana-Kilambi , what do you thing? Is this something you've considered?


That could be feasible, we might need to store two pointers - 
1. An off-heap `CodeBlob` field - `_code` pointing to the start of its CodeHeap block. Boundary accessors in `CodeBlob` like `code_begin()`, `code_end()`, `data_begin()` etc would derive from this pointer
2. A tiny back-pointer at the start of each `CodeHeap` block that holds  the owning `CodeBlob*`. This might be needed by `CodeCache::find_blob(void* start)` to return the off-heap `CodeBlob*`

However, I do agree with @mikabl-arm that this significantly broadens the scope of this patch. Moving the entire `CodeBlob` object out of the CodeCache touches every blob subtype, SA, any code that walks/iterates through all blobs in the code cache etc. From what we have observed, a considerable part of the `CodeCache` is occupied mainly by the non-profiled and profiled nmethods. Thus, the goal of this patch is to reduce the footprint of the nmethod object first (to make them as compact as possible), without changing the global lookup paths. Would it be okay for us to keep the current scope of this patch to move the nmethod header to off-heap memory and maybe create a new RFE to explore moving CodeBlob header to off-heap memory?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3682508777

From iklam at openjdk.org  Mon Dec 22 18:09:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 22 Dec 2025 18:09:14 GMT
Subject: RFR: 8374177: Update @since of HotSpotAOTCacheMXBean after
 JDK-8373607
In-Reply-To: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
References: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
Message-ID: <v6_simiaLodiXWljjTxX3gPWHp8WSK6JkWIKCb8u8jQ=.0e32ea78-3cb5-408c-af20-15aac1ec49dc@github.com>

On Sun, 21 Dec 2025 14:05:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

Looks good. Thanks for taking care of this.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28944#pullrequestreview-3605157378

From cjplummer at openjdk.org  Mon Dec 22 19:05:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 19:05:19 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
 <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
Message-ID: <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>

On Mon, 22 Dec 2025 08:44:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.
>> 
>> After I change the value of MAX_ITERATIONS to 50, The test run passed, and the test log shows that the number of unloaded enents is different every time.
>> 
>> 
>> Number of unloaded events 12 number of iterations 25
>> Number of unloaded events 1 number of iterations 36
>> Number of unloaded events 4 number of iterations 30
>> 
>> 
>> Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.
>> 
>> Maybe that's why after this PR we need more try loop count to get the unload enent.
>> 
>> And if I add Thread.sleep(5000) after unloadClass() call  also make this test pass without change the value of MAX_ITERATIONS.
>> 
>> And I found that the vaule of MAX_ITERATIONS set to 50 seems do not enough. This will intermittent fails when run this test serially many times. So I change it to 500.
>
> Another solution is make some sleep after call `unloadClass()`
> 
> 
> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> index 13058ec7864..15120d3cad6 100644
> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> @@ -47,7 +47,7 @@ public class compmethunload001 {
>      private final static String CLS_TO_BE_UNLOADED =
>          "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>  
> -    private final static int MAX_ITERATIONS = 50;
> +    private final static int MAX_ITERATIONS = 5;
>  
>      static {
>          try {
> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
>  
>          boolean clsUnloaded = clsUnLoader.unloadClass();
>          clsUnLoader = null;
> +        Thread.sleep(5000);
>          System.gc();
>      }

It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2640938897

From cjplummer at openjdk.org  Mon Dec 22 19:11:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 19:11:07 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <JlezalZ4_MpnOmqU1w7CksKbZHxF8YOcmOMgVijzxOU=.6943146c-dd5f-498d-905a-c14354b1f31c@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java line 83:

> 81:                 updateCounters();
> 82:                 validate(false /* don't check gc count increases */);
> 83:                 Algorithms.eatMemory(stresser);

Are you going to file a separate issue to use WB.fullGC()? Are there other monitoring tests that could also benefit from this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28923#discussion_r2640952242

From dlong at openjdk.org  Mon Dec 22 19:29:56 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 22 Dec 2025 19:29:56 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
 <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
 <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>
Message-ID: <hK-Ezcz9awUlneOcSnjUmnx81mWkZ8Yugj4QuAAG1z4=.17e436b3-690b-46ca-88ea-dcba5af99b55@github.com>

On Mon, 22 Dec 2025 15:16:54 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Would it be okay for us to keep the current scope of this patch to move the nmethod header to off-heap memory and maybe create a new RFE to explore moving CodeBlob header to off-heap memory?

That's fine with me.  I was thinking it would be comparable in complexity, but I hadn't worked it out as far as you have.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3683832810

From cjplummer at openjdk.org  Mon Dec 22 19:31:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 19:31:06 GMT
Subject: RFR: 8374038: JDI EventRequestManager javadoc has unrendered @link
 tags inside an @code block [v2]
In-Reply-To: <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
References: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
 <q_ly_zgHBWh6t5_3yt-nlE0HzkmUH3n1JVSsoNyVfOk=.635921de-bb20-479c-8c70-8531a0bd7702@github.com>
Message-ID: <Vdsjwx-OPtbc87YXJslNJD2NxOW5_wrrTAPfZcOfKrU=.6558bcc9-44af-4ffa-a4dd-b01a57f00f43@github.com>

On Thu, 18 Dec 2025 23:07:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.
>> 
>> Here's what the current version looks like before any fixes: https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/EventRequestManager.html#createStepRequest(com.sun.jdi.ThreadReference,int,int)
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8374038_ERM_javadoc
>    Merge
>  - fix minor typo
>  - fix minor typo
>  - Remove @links from @code blocks

Thank you for the reviews Alex and Kevin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28907#issuecomment-3683830909

From cjplummer at openjdk.org  Mon Dec 22 19:31:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 19:31:07 GMT
Subject: Integrated: 8374038: JDI EventRequestManager javadoc has unrendered
 @link tags inside an @code block
In-Reply-To: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
References: <P4aQ8rcQ3B3AhFDpI7nhPmcDOyHFQ_jDnBpteiYQODU=.93041eb5-6ab9-4861-afee-ca851a491635@github.com>
Message-ID: <Xn4MBPxBTvIdVmcerGyYVI-qw_oZj4lcAl3-a0fITVM=.c010bb99-562c-48a9-aa84-f6c3491bca99@github.com>

On Thu, 18 Dec 2025 20:04:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Get rid of @link blocks embedded inside @code block since they are not rendered. I searched the rendered JDI javadoc for additional @link references showing up as raw text and didn't find any.
> 
> Here's what the current version looks like before any fixes: https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/EventRequestManager.html#createStepRequest(com.sun.jdi.ThreadReference,int,int)

This pull request has now been integrated.

Changeset: 72505420
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72505420ca22c2ba1584f9d401ff0a1047b8c79b
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8374038: JDI EventRequestManager javadoc has unrendered @link tags inside an @code block

Reviewed-by: kevinw, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/28907

From amenkov at openjdk.org  Mon Dec 22 20:35:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 22 Dec 2025 20:35:14 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v2]
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <WSjLr2zZ8LY_gle0PGWgcJR6ecLbqbqSzgEgkuG-SNw=.b70b9e19-2069-4287-9ad2-1fd92d93b0d2@github.com>

> The fix resolves disabled warnings in debugger agent

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28937/files
  - new: https://git.openjdk.org/jdk/pull/28937/files/339229c2..79cfd6e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=00-01

  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From amenkov at openjdk.org  Mon Dec 22 20:35:17 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 22 Dec 2025 20:35:17 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v2]
In-Reply-To: <9lmjHGrV6x6050WJNE1iF1DuDY2CN-slOW0Hm0LtJi0=.eb972bb0-e781-4740-9817-b74bd66d1c82@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <9lmjHGrV6x6050WJNE1iF1DuDY2CN-slOW0Hm0LtJi0=.eb972bb0-e781-4740-9817-b74bd66d1c82@github.com>
Message-ID: <U6NeRSoU8iwGxETUH62fiGdzxf_cBTfx77WK4pOHzfo=.33c29e12-c251-49c8-b2e5-222ce580c83e@github.com>

On Sat, 20 Dec 2025 02:39:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 980:
> 
>> 978: {
>> 979:     // PlatformThreadsFilter contains nothing useful
>> 980:     //PlatformThreadsFilter *filter = &FILTER(node, index).u.PlatformThreadsOnly;
> 
> I think you can just delete this.

deleted

> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2678:
> 
>> 2676:     if (error != JVMTI_ERROR_NONE) {
>> 2677:         EXIT_ERROR(error, "cannot get current thread");
>> 2678:     }
> 
> I'm not sure about his one since it is a behavior change. For example, we have:
> 
>     jthread thread = threadControl_currentThread();
>     if ((thread != NULL) && (!threadControl_isDebugThread(thread))) {
>         threadControl_setPendingInterrupt(thread);
>     }

Looks like it can be called in wrong phase. dropped EXIT_ERROR and added explicit note that the function returns NULL on error

> src/jdk.jdwp.agent/share/native/libjdwp/util.h line 64:
> 
>> 62: /* To handle "format string is not a string literal" warning. */
>> 63: #if !defined(_MSC_VER)
>> 64:   #define ATTRIBUTE_PRINTF(fmt, vargs)  __attribute__((format(printf, fmt, vargs)))
> 
> Why not ATTRIBUTE_FORMAT?

printf is essential here, attribute(format) also support other functions - scanf, strftime, strfmon

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641151638
PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641153882
PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641157278

From sspitsyn at openjdk.org  Mon Dec 22 21:33:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 22 Dec 2025 21:33:57 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
Message-ID: <y4qLcR8bml9OCG6tdH3XTmxHIjKXwITK0fA4B4xJAPM=.f8c70827-08cb-4768-93d9-ce58edffca7f@github.com>

On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Delay suspender whilst target is in-critical
>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>    
>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.

I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections:

HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) {
  assert(_handshakee == Thread::current(), "Must be called by self");
  assert(_lock.owned_by_self(), "Lock must be held");
  assert(allow_suspend || !check_async_exception, "invalid case");
#if INCLUDE_JVMTI
  if (allow_suspend && _handshakee->is_disable_suspend()) {                                <== !!!
    // filter out suspend operations while JavaThread is in disable_suspend mode
    allow_suspend = false;
  }
#endif
  if (!allow_suspend) {
    return _queue.peek(no_suspend_no_async_exception_filter);
  } else if (check_async_exception && !_async_exceptions_blocked) {
    return _queue.peek();
  } else {
    return _queue.peek(no_async_exception_filter);
  }
}


The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684247689

From cjplummer at openjdk.org  Mon Dec 22 21:40:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 21:40:07 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v2]
In-Reply-To: <WSjLr2zZ8LY_gle0PGWgcJR6ecLbqbqSzgEgkuG-SNw=.b70b9e19-2069-4287-9ad2-1fd92d93b0d2@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <WSjLr2zZ8LY_gle0PGWgcJR6ecLbqbqSzgEgkuG-SNw=.b70b9e19-2069-4287-9ad2-1fd92d93b0d2@github.com>
Message-ID: <HX_OreYkUUOfDYUHKwA9o6-_vgBXaCyZSHiEeBH3_ek=.56cf53b2-fb68-41fd-bf71-480ad592e01b@github.com>

On Mon, 22 Dec 2025 20:35:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3605830919

From dholmes at openjdk.org  Mon Dec 22 22:03:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 22:03:00 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <y4qLcR8bml9OCG6tdH3XTmxHIjKXwITK0fA4B4xJAPM=.f8c70827-08cb-4768-93d9-ce58edffca7f@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <y4qLcR8bml9OCG6tdH3XTmxHIjKXwITK0fA4B4xJAPM=.f8c70827-08cb-4768-93d9-ce58edffca7f@github.com>
Message-ID: <mCr63ZFHcbO364Us_eVEyShgE3gsqWhwxTotR0DZ4aE=.ec631014-2948-4fdb-924a-28b7f07a0a00@github.com>

On Mon, 22 Dec 2025 21:30:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Delay suspender whilst target is in-critical
>>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>>    
>>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.
>
> I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections:
> 
> HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) {
>   assert(_handshakee == Thread::current(), "Must be called by self");
>   assert(_lock.owned_by_self(), "Lock must be held");
>   assert(allow_suspend || !check_async_exception, "invalid case");
> #if INCLUDE_JVMTI
>   if (allow_suspend && _handshakee->is_disable_suspend()) {                                <== !!!
>     // filter out suspend operations while JavaThread is in disable_suspend mode
>     allow_suspend = false;
>   }
> #endif
>   if (!allow_suspend) {
>     return _queue.peek(no_suspend_no_async_exception_filter);
>   } else if (check_async_exception && !_async_exceptions_blocked) {
>     return _queue.peek();
>   } else {
>     return _queue.peek(no_async_exception_filter);
>   }
> }
> 
> 
> The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead.
> 
> Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section.

@sspitsyn The use of `is_disable_suspend` is what was originally proposed but it does not work as it does not do what might be expected. Further none of these suggestions deep in the handshake code deal with the problem that the thread requesting the suspend has to block as long as any target is "in critical". I cannot see a relatively simple solution to this, but rather we would need a new (and complex) protocol for trying to deal with this. One possible approach may be to use a Dekker-style dual check and also permit JNI-critical to be blocked if a suspend request is pending.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684317025

From sspitsyn at openjdk.org  Mon Dec 22 22:15:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 22 Dec 2025 22:15:08 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions [v2]
In-Reply-To: <mCr63ZFHcbO364Us_eVEyShgE3gsqWhwxTotR0DZ4aE=.ec631014-2948-4fdb-924a-28b7f07a0a00@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
 <y4qLcR8bml9OCG6tdH3XTmxHIjKXwITK0fA4B4xJAPM=.f8c70827-08cb-4768-93d9-ce58edffca7f@github.com>
 <mCr63ZFHcbO364Us_eVEyShgE3gsqWhwxTotR0DZ4aE=.ec631014-2948-4fdb-924a-28b7f07a0a00@github.com>
Message-ID: <rvs8UDhvnL7sc_t5WAIBmDBL0cZAlxZBED6DGSAsoMw=.b8d3ada0-3d69-4ded-bef0-11e7f0c19c98@github.com>

On Mon, 22 Dec 2025 22:00:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections:
>> 
>> HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) {
>>   assert(_handshakee == Thread::current(), "Must be called by self");
>>   assert(_lock.owned_by_self(), "Lock must be held");
>>   assert(allow_suspend || !check_async_exception, "invalid case");
>> #if INCLUDE_JVMTI
>>   if (allow_suspend && _handshakee->is_disable_suspend()) {                                <== !!!
>>     // filter out suspend operations while JavaThread is in disable_suspend mode
>>     allow_suspend = false;
>>   }
>> #endif
>>   if (!allow_suspend) {
>>     return _queue.peek(no_suspend_no_async_exception_filter);
>>   } else if (check_async_exception && !_async_exceptions_blocked) {
>>     return _queue.peek();
>>   } else {
>>     return _queue.peek(no_async_exception_filter);
>>   }
>> }
>> 
>> 
>> The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead.
>> 
>> Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section.
>
> @sspitsyn The use of `is_disable_suspend` is what was originally proposed but it does not work as it does not do what might be expected. Further none of these suggestions deep in the handshake code deal with the problem that the thread requesting the suspend has to block as long as any target is "in critical". I cannot see a relatively simple solution to this, but rather we would need a new (and complex) protocol for trying to deal with this. One possible approach may be to use a Dekker-style dual check and also permit JNI-critical to be blocked if a suspend request is pending.

@dholmes-ora Probably, you missed this update at the end of my comment:

> Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684354390

From sspitsyn at openjdk.org  Mon Dec 22 23:14:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 22 Dec 2025 23:14:53 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v2]
In-Reply-To: <WSjLr2zZ8LY_gle0PGWgcJR6ecLbqbqSzgEgkuG-SNw=.b70b9e19-2069-4287-9ad2-1fd92d93b0d2@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <WSjLr2zZ8LY_gle0PGWgcJR6ecLbqbqSzgEgkuG-SNw=.b70b9e19-2069-4287-9ad2-1fd92d93b0d2@github.com>
Message-ID: <252P1WwaXISe9qXg5GMwj-FOePC77BSxT21CA8Y61zA=.1dadd8f0-57d1-449c-b71c-7b17d53f4ea0@github.com>

On Mon, 22 Dec 2025 20:35:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Looks good. Posted one nit.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3606044413

From sspitsyn at openjdk.org  Mon Dec 22 23:14:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 22 Dec 2025 23:14:55 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v2]
In-Reply-To: <U6NeRSoU8iwGxETUH62fiGdzxf_cBTfx77WK4pOHzfo=.33c29e12-c251-49c8-b2e5-222ce580c83e@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <9lmjHGrV6x6050WJNE1iF1DuDY2CN-slOW0Hm0LtJi0=.eb972bb0-e781-4740-9817-b74bd66d1c82@github.com>
 <U6NeRSoU8iwGxETUH62fiGdzxf_cBTfx77WK4pOHzfo=.33c29e12-c251-49c8-b2e5-222ce580c83e@github.com>
Message-ID: <scih-pilzjjNEWf1UmaVKvZBBQ9f_JbR7_P4LCQdzvg=.63a02fa0-a634-4547-b75d-2aaaf8a2d0c0@github.com>

On Mon, 22 Dec 2025 20:31:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.h line 64:
>> 
>>> 62: /* To handle "format string is not a string literal" warning. */
>>> 63: #if !defined(_MSC_VER)
>>> 64:   #define ATTRIBUTE_PRINTF(fmt, vargs)  __attribute__((format(printf, fmt, vargs)))
>> 
>> Why not ATTRIBUTE_FORMAT?
>
> printf is essential here, attribute(format) also support other functions - scanf, strftime, strfmon

Nit: The macro parameter names are confusing. I'd suggest to rename them to something like `fmt_pos_num` and `vargs_pos_num`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641489071

From sspitsyn at openjdk.org  Mon Dec 22 23:55:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 22 Dec 2025 23:55:56 GMT
Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical
 regions
In-Reply-To: <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <maCtDXw4mZHYiKQFOy3Zx15HdyrmUuedhycquT_kTzI=.232a9865-67da-4b1b-9aa3-78b4c81f04f0@github.com>
 <LeZa3-hGjRo0O4AxUwoPsgeMgMXA5gaJ5rRtQcJziNY=.fe3a8cbb-3b65-4432-81c6-77cf1bb83e14@github.com>
 <ojEXgmQwtE7EvA5vR7yzygV_pZOFG4RByiuRdFmaxEU=.39b8f455-fdec-471c-abcf-5c1402228996@github.com>
 <Oou2S193-bghY6YdrKxHW_h9T7SduMlSOpLtCq6uKk4=.3c3febc0-1a89-41c9-b113-0585cfe44d88@github.com>
 <Xeg9vmuxuvZmQs2Gdr4kG4BAt1Ngexa0bgpAIMLaaIQ=.902c07e5-919d-4982-8e63-3d1e76908dc5@github.com>
 <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com>
Message-ID: <uNrbv9okGeIngX462_UI047bn5DkriBJVY7ka98r9Hw=.f177e95a-0e76-405b-9ec5-74b713771caa@github.com>

On Mon, 22 Dec 2025 01:32:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That isn't really any better to me. The general purpose handshake code should not have to be JNI-critical aware.

Agreed. It is not easy to track what was already discussed in this chat. Most likely, you already touched this but just wanted to double check. This issue is not fixable on the handshake code side. At the time the `SuspendThreadHandshakeClosure` op is executed, the target thread can be in native but not executing JNI critical region yet. However, after the `SuspendThreadHandshakeClosure` op has been finished (the suspend has been completed from the suspender point of view) the target thread can enter a JNI critical region while still in native and before having any chance to be self-suspended with the`ThreadSelfSuspensionHandshakeClosure`.
In opposite, the JNI-critical code can to be JVMTI suspend aware. It can block on entering JNI critical region while the thread is suspended. However, this approach can cause new deadlocks. Good news is that the debug agent does not use JNI critical regions (AFAIKS).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684572911

From sspitsyn at openjdk.org  Tue Dec 23 00:05:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Dec 2025 00:05:17 GMT
Subject: RFR: 8373366: HandshakeState should disallow suspend ops for
 disabler threads [v4]
In-Reply-To: <GAlogwnN7y7jIhmeVF_IPSdEylEnUgXTWkqeHoHCUbk=.5f8fdec6-c925-4b1b-bc12-1cb3f9666d0e@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
 <GAlogwnN7y7jIhmeVF_IPSdEylEnUgXTWkqeHoHCUbk=.5f8fdec6-c925-4b1b-bc12-1cb3f9666d0e@github.com>
Message-ID: <w90u_S7HydH2SbJiSto4Ycoy7rN8uSP2FG-xCvID61w=.4f4a663a-e306-4efd-aec2-ef610817c43c@github.com>

On Thu, 18 Dec 2025 04:33:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If all you are doing is adding an assert then the JBS issue and the PR need a considerable rewrite to explain things.

Agreed. We had a private slack discussion with Patricio and decided to construct a test case to catch this situation. I've decided to postpone JBS and PR description changes while I'm working on test coverage. I had to place a comment about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3684586748

From ysuenaga at openjdk.org  Tue Dec 23 00:39:15 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 23 Dec 2025 00:39:15 GMT
Subject: [jdk26] RFR: 8373110: jstack --mixed frames are broken on macOS after
 JDK-8371194
Message-ID: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>

Hi all,

This pull request contains a backport of commit [b848ddf6](https://github.com/openjdk/jdk/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Yasumasa Suenaga on 18 Dec 2025 and was reviewed by Chris Plummer and Kevin Walls.

Thanks!

-------------

Commit messages:
 - Backport b848ddf6d3bf4e76d409b03be7f36199dadb2c5f

Changes: https://git.openjdk.org/jdk/pull/28958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373110
  Stats: 97 lines in 3 files changed: 68 ins; 3 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28958/head:pull/28958

PR: https://git.openjdk.org/jdk/pull/28958

From dholmes at openjdk.org  Tue Dec 23 01:06:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Dec 2025 01:06:53 GMT
Subject: [jdk26] RFR: 8373110: jstack --mixed frames are broken on macOS
 after JDK-8371194
In-Reply-To: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
References: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
Message-ID: <l-f8fCSiMIYAOojZ1jpS9crArDKQLoGNbP72vwMt4cA=.c3a7c8c6-4a6c-4a95-ad13-b975796979af@github.com>

On Tue, 23 Dec 2025 00:31:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b848ddf6](https://github.com/openjdk/jdk/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Yasumasa Suenaga on 18 Dec 2025 and was reviewed by Chris Plummer and Kevin Walls.
> 
> Thanks!

LGTM.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28958#pullrequestreview-3606199497

From amenkov at openjdk.org  Tue Dec 23 01:33:31 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 01:33:31 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v3]
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>

> The fix resolves disabled warnings in debugger agent

Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:

 - copyright
 - renamed define args
 - fixed windows GHA build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28937/files
  - new: https://git.openjdk.org/jdk/pull/28937/files/79cfd6e3..35ccaf32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=01-02

  Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From cjplummer at openjdk.org  Tue Dec 23 01:54:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 01:54:53 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v3]
In-Reply-To: <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
Message-ID: <kmwnAoF7tqivSoN6VULGe_UEOoCiiJ79WgHaswRvVQ8=.8e997f6f-1c15-4a7a-afc3-bc167f2e72d8@github.com>

On Tue, 23 Dec 2025 01:33:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - copyright
>  - renamed define args
>  - fixed windows GHA build

src/jdk.jdwp.agent/share/native/libjdwp/util.h line 64:

> 62: /* To handle "format string is not a string literal" warning. */
> 63: #if !defined(_MSC_VER)
> 64:   #define ATTRIBUTE_PRINTF(fmt_pos_num, vargs_pos_num)  __attribute__((format(printf, fmt_pos_num, vargs_pos_num)))

The line is kind of long now. Maybe start the definition on a new line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641695644

From cjplummer at openjdk.org  Tue Dec 23 02:02:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 02:02:54 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v3]
In-Reply-To: <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
Message-ID: <-XR1WBvyb2Av2OMxlFDzdvxQH6qC5HQGAtkYSgOXgN4=.9c26d02f-71f8-478d-8b43-1514a1b5508d@github.com>

On Tue, 23 Dec 2025 01:33:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - copyright
>  - renamed define args
>  - fixed windows GHA build

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 189:

> 187:                                         >> (int)JVMTI_VERSION_SHIFT_MINOR;
> 188:     jvmtiCompileTimeMicroVersion  = ((int)JVMTI_VERSION & (int)JVMTI_VERSION_MASK_MICRO)
> 189:                                         >> (int)JVMTI_VERSION_SHIFT_MICRO;

Can you explain the need for this. These types are all naturally jints, so I'm not sure why you would need to cast them here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641704037

From cjplummer at openjdk.org  Tue Dec 23 02:06:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 02:06:58 GMT
Subject: [jdk26] RFR: 8373110: jstack --mixed frames are broken on macOS
 after JDK-8371194
In-Reply-To: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
References: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
Message-ID: <IOwtqoyk-WTu0FQ1D2rbB8pO9D9PZvpTlNAB3ArqH3k=.26e58bc3-170e-4137-80ba-4b591733734a@github.com>

On Tue, 23 Dec 2025 00:31:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b848ddf6](https://github.com/openjdk/jdk/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Yasumasa Suenaga on 18 Dec 2025 and was reviewed by Chris Plummer and Kevin Walls.
> 
> Thanks!

Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28958#pullrequestreview-3606281171

From amenkov at openjdk.org  Tue Dec 23 02:33:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 02:33:32 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <dTDVUBXEkas_lu5S6e_kui5mhiSx9EZ838vl8NYncC0=.96032322-e3a3-45ae-824e-1cba80077e9a@github.com>

> The fix resolves disabled warnings in debugger agent

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  break long line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28937/files
  - new: https://git.openjdk.org/jdk/pull/28937/files/35ccaf32..8548586d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From amenkov at openjdk.org  Tue Dec 23 02:33:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 02:33:34 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v3]
In-Reply-To: <kmwnAoF7tqivSoN6VULGe_UEOoCiiJ79WgHaswRvVQ8=.8e997f6f-1c15-4a7a-afc3-bc167f2e72d8@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
 <kmwnAoF7tqivSoN6VULGe_UEOoCiiJ79WgHaswRvVQ8=.8e997f6f-1c15-4a7a-afc3-bc167f2e72d8@github.com>
Message-ID: <bA9yI_aG9uNjpZUz9i_3o4Gv5iklVSu0X4Js-ghnvkQ=.572ceb3a-1d89-44a3-92fd-510d049fe6e7@github.com>

On Tue, 23 Dec 2025 01:52:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - copyright
>>  - renamed define args
>>  - fixed windows GHA build
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.h line 64:
> 
>> 62: /* To handle "format string is not a string literal" warning. */
>> 63: #if !defined(_MSC_VER)
>> 64:   #define ATTRIBUTE_PRINTF(fmt_pos_num, vargs_pos_num)  __attribute__((format(printf, fmt_pos_num, vargs_pos_num)))
> 
> The line is kind of long now. Maybe start the definition on a new line.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641743174

From amenkov at openjdk.org  Tue Dec 23 02:38:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 02:38:53 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <-XR1WBvyb2Av2OMxlFDzdvxQH6qC5HQGAtkYSgOXgN4=.9c26d02f-71f8-478d-8b43-1514a1b5508d@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
 <-XR1WBvyb2Av2OMxlFDzdvxQH6qC5HQGAtkYSgOXgN4=.9c26d02f-71f8-478d-8b43-1514a1b5508d@github.com>
Message-ID: <oioYew6Xud7ZLW72dxToJteAt7EG1tgzRYYuJVS-lUY=.abf3774a-9022-44dd-8930-6bf2674dc41a@github.com>

On Tue, 23 Dec 2025 01:59:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   break long line
>
> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 189:
> 
>> 187:                                         >> (int)JVMTI_VERSION_SHIFT_MINOR;
>> 188:     jvmtiCompileTimeMicroVersion  = ((int)JVMTI_VERSION & (int)JVMTI_VERSION_MASK_MICRO)
>> 189:                                         >> (int)JVMTI_VERSION_SHIFT_MICRO;
> 
> Can you explain the need for this. These types are all naturally jints, so I'm not sure why you would need to cast them here.

These are enums (i.e. ints) , GHA on Windows fail because they are 3 different enum types (warning 5287)
For unknown reason (different MSVC version maybe) my local Windows build and our CI passed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641749094

From cjplummer at openjdk.org  Tue Dec 23 02:48:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 02:48:52 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <oioYew6Xud7ZLW72dxToJteAt7EG1tgzRYYuJVS-lUY=.abf3774a-9022-44dd-8930-6bf2674dc41a@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
 <-XR1WBvyb2Av2OMxlFDzdvxQH6qC5HQGAtkYSgOXgN4=.9c26d02f-71f8-478d-8b43-1514a1b5508d@github.com>
 <oioYew6Xud7ZLW72dxToJteAt7EG1tgzRYYuJVS-lUY=.abf3774a-9022-44dd-8930-6bf2674dc41a@github.com>
Message-ID: <r9F4XdEe6CqBeAdbomjPXbWjfI1WSqWeuq_1gRgVVA0=.d41b38a0-3940-4f68-8dcc-79116153d783@github.com>

On Tue, 23 Dec 2025 02:35:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> These are enums (i.e. ints) , GHA on Windows fail because they are 3 different enum types (warning 5287)
> For unknown reason (different MSVC version maybe) my local Windows build and our CI passed

This code that we have elsewhere in the debug agent seems to compile ok. Perhaps all that is needed is a cast of JVMTI_VERSION to jint:


static jboolean isVersionGte12x() {
    jint version;
    jvmtiError err =
        JVMTI_FUNC_PTR(gdata->jvmti,GetVersionNumber)(gdata->jvmti, &version);

    if (err == JVMTI_ERROR_NONE) {
        jint major, minor;

        major = (version & JVMTI_VERSION_MASK_MAJOR)
                    >> JVMTI_VERSION_SHIFT_MAJOR;
        minor = (version & JVMTI_VERSION_MASK_MINOR)
                    >> JVMTI_VERSION_SHIFT_MINOR;
        return (major > 1 || (major == 1 && minor >= 2)) ? JNI_TRUE : JNI_FALSE;
    } else {
        return JNI_FALSE;
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2641762486

From syan at openjdk.org  Tue Dec 23 04:04:22 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 04:04:22 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
 <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
 <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>
Message-ID: <wAusmw-EGpJttFkzRfxmexm6VP2SREMcsNn34DH3718=.66d40953-d88a-4b28-bd10-950cd3a1b3de@github.com>

On Mon, 22 Dec 2025 19:01:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Another solution is make some sleep after call `unloadClass()`
>> 
>> 
>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> index 13058ec7864..15120d3cad6 100644
>> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> @@ -47,7 +47,7 @@ public class compmethunload001 {
>>      private final static String CLS_TO_BE_UNLOADED =
>>          "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>>  
>> -    private final static int MAX_ITERATIONS = 50;
>> +    private final static int MAX_ITERATIONS = 5;
>>  
>>      static {
>>          try {
>> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
>>  
>>          boolean clsUnloaded = clsUnLoader.unloadClass();
>>          clsUnLoader = null;
>> +        Thread.sleep(5000);
>>          System.gc();
>>      }
>
> It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens.

The code "wait on a monitor and notify from JNI" seems too complex for me. So I just limit the loop to no more than 10 seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2641853242

From sspitsyn at openjdk.org  Tue Dec 23 04:20:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Dec 2025 04:20:01 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <dTDVUBXEkas_lu5S6e_kui5mhiSx9EZ838vl8NYncC0=.96032322-e3a3-45ae-824e-1cba80077e9a@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <dTDVUBXEkas_lu5S6e_kui5mhiSx9EZ838vl8NYncC0=.96032322-e3a3-45ae-824e-1cba80077e9a@github.com>
Message-ID: <lFAxIEMwv7YgG02FCDRfd7vImvEOVg2w4kXSOUpLwSc=.4f24e19f-cd5f-4ade-8baf-288037aa0833@github.com>

On Tue, 23 Dec 2025 02:33:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   break long line

Thank you for the updates. Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3606479475

From syan at openjdk.org  Tue Dec 23 06:18:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 06:18:11 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v9]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <57mV8My9uVrRQwWkkizAkRt0U_XKsOTwGYjvSRGoP6c=.3e83f7a9-977f-43a3-bf35-c4fb1e86a9b0@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/567c7623..e8d128e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07-08

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Tue Dec 23 06:56:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 06:56:44 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v10]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <1SRvteO27ODfuUPUyovzjAHeTA_BH0-wcc5ODyiSJIo=.1fe140cf-239f-4303-8cbe-d4f884c4ffc6@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Fix the copy-n-paste error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/e8d128e6..349ae833

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08-09

  Stats: 24 lines in 4 files changed: 0 ins; 20 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Tue Dec 23 07:32:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 07:32:47 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update commnets for ClassUnloader

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/349ae833..6c144309

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From ysuenaga at openjdk.org  Tue Dec 23 09:20:11 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 23 Dec 2025 09:20:11 GMT
Subject: [jdk26] Integrated: 8373110: jstack --mixed frames are broken on macOS
 after JDK-8371194
In-Reply-To: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
References: <8mFZTHlEZTfNQxknwf094GtnZfmFslIDAzFZTfpSyiU=.e1187a51-235c-4242-be60-d60c7b05c4f8@github.com>
Message-ID: <LAiKHu5leTIcUouIzICQgqODGJylH0dTS6-dc5mfiH8=.28c35404-e3aa-42ba-ac4e-5b3bd34e4277@github.com>

On Tue, 23 Dec 2025 00:31:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b848ddf6](https://github.com/openjdk/jdk/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Yasumasa Suenaga on 18 Dec 2025 and was reviewed by Chris Plummer and Kevin Walls.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cece06f1
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cece06f1aab888d337d67bfe08208c073547fb92
Stats:     97 lines in 3 files changed: 68 ins; 3 del; 26 mod

8373110: jstack --mixed frames are broken on macOS after JDK-8371194

Reviewed-by: dholmes
Backport-of: b848ddf6d3bf4e76d409b03be7f36199dadb2c5f

-------------

PR: https://git.openjdk.org/jdk/pull/28958

From kevinw at openjdk.org  Tue Dec 23 09:31:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 09:31:55 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <JlezalZ4_MpnOmqU1w7CksKbZHxF8YOcmOMgVijzxOU=.6943146c-dd5f-498d-905a-c14354b1f31c@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
 <JlezalZ4_MpnOmqU1w7CksKbZHxF8YOcmOMgVijzxOU=.6943146c-dd5f-498d-905a-c14354b1f31c@github.com>
Message-ID: <MQgKkhXHPHCtUiylHuuGt1JOfFV20PNJUZErVQHRkW0=.5c4ccb70-fcb5-4588-8162-3bc5a7721e15@github.com>

On Mon, 22 Dec 2025 19:07:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
>> 
>> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
>> Limiting to 5 iterations.
>> 
>> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
>> 
>> Tests that do some allocation and check for a collection can be unreliable.
>> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
>> 
>> I'd like to get this change in though, as the test may fail more now than before.
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java line 83:
> 
>> 81:                 updateCounters();
>> 82:                 validate(false /* don't check gc count increases */);
>> 83:                 Algorithms.eatMemory(stresser);
> 
> Are you going to file a separate issue to use WB.fullGC()? Are there other monitoring tests that could also benefit from this?

Yes, would like to integrate this one soon as it makes the test more reliable, my earlier change may have made it less reliable (it tests more aggressively, it never skips and likely does more iterations).  Want to follow up with a survey of what other tests the Whitebox can be useful for, maybe not just this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28923#discussion_r2642560582

From kevinw at openjdk.org  Tue Dec 23 09:55:09 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 09:55:09 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp
Message-ID: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>

Comment-only cleanup, didn't spot during previous review.

Trivial, no code affected.

-------------

Commit messages:
 - 8374232: Comment cleanup in diagnosticCommand.cpp

Changes: https://git.openjdk.org/jdk/pull/28962/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374232
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28962.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28962/head:pull/28962

PR: https://git.openjdk.org/jdk/pull/28962

From kbarrett at openjdk.org  Tue Dec 23 12:15:00 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 23 Dec 2025 12:15:00 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <r9F4XdEe6CqBeAdbomjPXbWjfI1WSqWeuq_1gRgVVA0=.d41b38a0-3940-4f68-8dcc-79116153d783@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <3hckDUidsESqd3rsjeOg30-w-3v_WyJ0jP_pn1j6vPw=.4edd1ebc-f376-4a74-ab07-9cda97b9f628@github.com>
 <-XR1WBvyb2Av2OMxlFDzdvxQH6qC5HQGAtkYSgOXgN4=.9c26d02f-71f8-478d-8b43-1514a1b5508d@github.com>
 <oioYew6Xud7ZLW72dxToJteAt7EG1tgzRYYuJVS-lUY=.abf3774a-9022-44dd-8930-6bf2674dc41a@github.com>
 <r9F4XdEe6CqBeAdbomjPXbWjfI1WSqWeuq_1gRgVVA0=.d41b38a0-3940-4f68-8dcc-79116153d783@github.com>
Message-ID: <POyHHWbajodl8oYFIbIYlPzTKATrAeb1wfj731IDfVg=.f7795bc2-f9d7-4d80-bbc8-d38d47ca05df@github.com>

On Tue, 23 Dec 2025 02:46:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> These are enums (i.e. ints) , GHA on Windows fail because they are 3 different enum types (warning 5287)
>> For unknown reason (different MSVC version maybe) my local Windows build and our CI passed
>
>> These are enums (i.e. ints) , GHA on Windows fail because they are 3 different enum types (warning 5287)
>> For unknown reason (different MSVC version maybe) my local Windows build and our CI passed
> 
> This code that we have elsewhere in the debug agent seems to compile ok. Perhaps all that is needed is a cast of JVMTI_VERSION to jint:
> 
> 
> static jboolean isVersionGte12x() {
>     jint version;
>     jvmtiError err =
>         JVMTI_FUNC_PTR(gdata->jvmti,GetVersionNumber)(gdata->jvmti, &version);
> 
>     if (err == JVMTI_ERROR_NONE) {
>         jint major, minor;
> 
>         major = (version & JVMTI_VERSION_MASK_MAJOR)
>                     >> JVMTI_VERSION_SHIFT_MAJOR;
>         minor = (version & JVMTI_VERSION_MASK_MINOR)
>                     >> JVMTI_VERSION_SHIFT_MINOR;
>         return (major > 1 || (major == 1 && minor >= 2)) ? JNI_TRUE : JNI_FALSE;
>     } else {
>         return JNI_FALSE;
>     }
> }

Similarly, no warnings for `JvmtiExport::decode_version_values()`
https://github.com/openjdk/jdk/blob/e1d81c0946364a266a006481a8fbbac24c7e6c6a/src/hotspot/share/prims/jvmtiExport.cpp#L643-L648
where the version is a `jint`.
And `jint` does seem like the natural type here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28937#discussion_r2642993146

From cjplummer at openjdk.org  Tue Dec 23 15:35:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 15:35:07 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <9eoPVLJYENQTUdcRpokaI96F31If0pErI11Nc9iRr6k=.d43cb10f-0b70-4dda-b2f9-35e4f3d48134@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28923#pullrequestreview-3608454399

From cjplummer at openjdk.org  Tue Dec 23 15:49:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 15:49:09 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
In-Reply-To: <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
Message-ID: <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>

On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update commnets for ClassUnloader

Something strange is going on with this PR. I just get 3 separate emails for each of the following commits that were done in the past day:

- [Fix the copy-n-paste error](https://github.com/openjdk/jdk/pull/28891/changes/349ae833fb600ab9136ab4f43749d1e5f2c84ca0)
- [Update commnets for ClassUnloader](https://github.com/openjdk/jdk/pull/28891/changes/6c144309a091038aaed1d698bd12323f3672c7b9)
- [Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java](https://github.com/openjdk/jdk/pull/28891/changes/e8d128e666ee0a8cbbf6d9dc273636b62bd3fb96)

However, the PR claims that these commits were all done on Nov 22, not Dec.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3687093047

From cjplummer at openjdk.org  Tue Dec 23 15:59:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 15:59:14 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp
In-Reply-To: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
Message-ID: <KHxrTYKqRWej9ojMtnfeeVNIP1iFySmb0AP6ipsWnuA=.eae6dd4f-bbc0-4707-a58f-b383aec4752d@github.com>

On Tue, 23 Dec 2025 09:47:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Comment-only cleanup, didn't spot during previous review.
> 
> Trivial, no code affected.

src/hotspot/share/services/diagnosticCommand.cpp line 97:

> 95:   // Registration of the diagnostic commands.
> 96:   // Argument specifies to which interfaces a command is made available,
> 97:   // can also specify if hidden from jcmd help.

I kind a liked the "first argument, second argument" approach a bit more.

// First argument specifies on which interfaces a command is made available.
// Optional second argument specifies if hidden from jcmd help. Default is false.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643629971

From erikj at openjdk.org  Tue Dec 23 17:09:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 Dec 2025 17:09:55 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v4]
In-Reply-To: <dTDVUBXEkas_lu5S6e_kui5mhiSx9EZ838vl8NYncC0=.96032322-e3a3-45ae-824e-1cba80077e9a@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <dTDVUBXEkas_lu5S6e_kui5mhiSx9EZ838vl8NYncC0=.96032322-e3a3-45ae-824e-1cba80077e9a@github.com>
Message-ID: <u50JL40KebCufyA0Ca06rO5N1kqG7FWWFIpCr6lxJy8=.705e4128-8d70-41da-8918-57ad7541d330@github.com>

On Tue, 23 Dec 2025 02:33:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   break long line

Build change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3608755610

From kevinw at openjdk.org  Tue Dec 23 17:16:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 17:16:53 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp
In-Reply-To: <KHxrTYKqRWej9ojMtnfeeVNIP1iFySmb0AP6ipsWnuA=.eae6dd4f-bbc0-4707-a58f-b383aec4752d@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
 <KHxrTYKqRWej9ojMtnfeeVNIP1iFySmb0AP6ipsWnuA=.eae6dd4f-bbc0-4707-a58f-b383aec4752d@github.com>
Message-ID: <VfZDKlFTGwfcb0F8M_auixij_1I65g-1spATZIxYcjM=.6f0bf9a7-9ef9-4270-98f5-c76800d9d892@github.com>

On Tue, 23 Dec 2025 15:56:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Comment-only cleanup, didn't spot during previous review.
>> 
>> Trivial, no code affected.
>
> src/hotspot/share/services/diagnosticCommand.cpp line 97:
> 
>> 95:   // Registration of the diagnostic commands.
>> 96:   // Argument specifies to which interfaces a command is made available,
>> 97:   // can also specify if hidden from jcmd help.
> 
> I kind a liked the "first argument, second argument" approach a bit more.
> 
> // First argument specifies on which interfaces a command is made available.
> // Optional second argument specifies if hidden from jcmd help. Default is false.

OK thanks.
I was thinking as all the usages here only use one argument, the numbering seems irrelevant.
The flags/mask of sources is maybe unusual enough that it's worth keeping the comment.

I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed.
Any thoughts on if it's worth mentioning?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643824988

From sspitsyn at openjdk.org  Tue Dec 23 17:18:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Dec 2025 17:18:07 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
Message-ID: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>

Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.

The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.

Testing:
 - TBD: run mach5 tiers 1-6

-------------

Commit messages:
 - 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed

Changes: https://git.openjdk.org/jdk/pull/28965/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28965&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374233
  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28965/head:pull/28965

PR: https://git.openjdk.org/jdk/pull/28965

From cjplummer at openjdk.org  Tue Dec 23 18:03:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 18:03:45 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp
In-Reply-To: <VfZDKlFTGwfcb0F8M_auixij_1I65g-1spATZIxYcjM=.6f0bf9a7-9ef9-4270-98f5-c76800d9d892@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
 <KHxrTYKqRWej9ojMtnfeeVNIP1iFySmb0AP6ipsWnuA=.eae6dd4f-bbc0-4707-a58f-b383aec4752d@github.com>
 <VfZDKlFTGwfcb0F8M_auixij_1I65g-1spATZIxYcjM=.6f0bf9a7-9ef9-4270-98f5-c76800d9d892@github.com>
Message-ID: <BJeXMZEUagqODii5iv97He0A0lzzUFFbqTrYAheqEt0=.f86eafe0-d4ae-4e46-92c4-b822eca03224@github.com>

On Tue, 23 Dec 2025 17:14:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 97:
>> 
>>> 95:   // Registration of the diagnostic commands.
>>> 96:   // Argument specifies to which interfaces a command is made available,
>>> 97:   // can also specify if hidden from jcmd help.
>> 
>> I kind a liked the "first argument, second argument" approach a bit more.
>> 
>> // First argument specifies on which interfaces a command is made available.
>> // Optional second argument specifies if hidden from jcmd help. Default is false.
>
> OK thanks.
> I was thinking as all the usages here only use one argument, the numbering seems irrelevant.
> The flags/mask of sources is maybe unusual enough that it's worth keeping the comment.
> 
> I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed.
> Any thoughts on if it's worth mentioning?

Yeah, before adding my comment I had to first go digging for that `bool hidden = false` reference. At first it was unclear to me what the comment was even trying to describe. I think if you wanted to delete the comment that would be ok. I don't think we have a comment like this is any of the other numerous sections that register dcmds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643913760

From cjplummer at openjdk.org  Tue Dec 23 19:03:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 19:03:06 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
In-Reply-To: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
Message-ID: <cH-hQIzi3iTKN4b-CNr8_asyjl_iGn0V3c-9qnqoLmk=.30499228-9e0b-4eeb-a349-be7201387867@github.com>

On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
> 
> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
> 
> Testing:
>  - TBD: run mach5 tiers 1-6

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28965#pullrequestreview-3609036916

From amenkov at openjdk.org  Tue Dec 23 19:21:19 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 19:21:19 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v5]
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>

> The fix resolves disabled warnings in debugger agent

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  update for MS warning 5287 fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28937/files
  - new: https://git.openjdk.org/jdk/pull/28937/files/8548586d..64ca8bbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From kevinw at openjdk.org  Tue Dec 23 19:27:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 19:27:26 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2]
In-Reply-To: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
Message-ID: <vxUs2URtHp12njet6DNzYUtcLHbp3nDupB5fckXiWvs=.e7c9430a-4a81-4b69-9314-8ebf94961f76@github.com>

> Comment-only cleanup, didn't spot during previous review.
> 
> Trivial, no code affected.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28962/files
  - new: https://git.openjdk.org/jdk/pull/28962/files/d2f0eff1..7d2bab91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28962.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28962/head:pull/28962

PR: https://git.openjdk.org/jdk/pull/28962

From kevinw at openjdk.org  Tue Dec 23 19:31:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 19:31:53 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2]
In-Reply-To: <BJeXMZEUagqODii5iv97He0A0lzzUFFbqTrYAheqEt0=.f86eafe0-d4ae-4e46-92c4-b822eca03224@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
 <KHxrTYKqRWej9ojMtnfeeVNIP1iFySmb0AP6ipsWnuA=.eae6dd4f-bbc0-4707-a58f-b383aec4752d@github.com>
 <VfZDKlFTGwfcb0F8M_auixij_1I65g-1spATZIxYcjM=.6f0bf9a7-9ef9-4270-98f5-c76800d9d892@github.com>
 <BJeXMZEUagqODii5iv97He0A0lzzUFFbqTrYAheqEt0=.f86eafe0-d4ae-4e46-92c4-b822eca03224@github.com>
Message-ID: <63brWTy_pL7Vwh_KV1G6sxwlWSdXQJDEkegRRTzf0yM=.f19c9114-a3e8-4f63-84fa-d83ab7f7043d@github.com>

On Tue, 23 Dec 2025 18:00:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> OK thanks.
>> I was thinking as all the usages here only use one argument, the numbering seems irrelevant.
>> The flags/mask of sources is maybe unusual enough that it's worth keeping the comment.
>> 
>> I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed.
>> Any thoughts on if it's worth mentioning?
>
> Yeah, before adding my comment I had to first go digging for that `bool hidden = false` reference. At first it was unclear to me what the comment was even trying to describe. I think if you wanted to delete the comment that would be ok. I don't think we have a comment like this is any of the other numerous sections that register dcmds.

Yes, so removing the obscure hidden flag from the comment, it can just be:

void DCmd::register_dcmds() {  
  // Registration of the diagnostic commands.
  // Argument specifies on which interfaces a command is made available.

But as it is called register_dcmds, commenting that we do "Registration of the diagnostic commands." on the next line is obvious/unnecessary.

Updated!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2644095159

From cjplummer at openjdk.org  Tue Dec 23 19:38:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 19:38:54 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2]
In-Reply-To: <vxUs2URtHp12njet6DNzYUtcLHbp3nDupB5fckXiWvs=.e7c9430a-4a81-4b69-9314-8ebf94961f76@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
 <vxUs2URtHp12njet6DNzYUtcLHbp3nDupB5fckXiWvs=.e7c9430a-4a81-4b69-9314-8ebf94961f76@github.com>
Message-ID: <B_TezRdy8d5cK29OFPeTtdQVTXpPwaGsg9dc_QVqYEk=.628e0e77-a0f8-4989-8361-7fae42a17732@github.com>

On Tue, 23 Dec 2025 19:27:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Comment-only cleanup, didn't spot during previous review.
>> 
>> Trivial, no code affected.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28962#pullrequestreview-3609126842

From cjplummer at openjdk.org  Tue Dec 23 19:40:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 19:40:09 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v5]
In-Reply-To: <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
Message-ID: <A-KdjZVWP_naziYQ6BxDnZ80e3zXhERhwIjX-S77ou4=.35a180f1-1b5d-40e8-b5ac-66dbf9e95bfe@github.com>

On Tue, 23 Dec 2025 19:21:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update for MS warning 5287 fix

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3609130968

From kfarrell at openjdk.org  Tue Dec 23 19:58:17 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 19:58:17 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v4]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <w2ycxoCPdDFS6XkMxuwxGxEH77cm16W7HQknJL9vdR4=.9bee21b2-da7d-4e47-b052-a085d7826a47@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  timed loop for aix and linux proc read

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/bd00e399..7170aa06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=02-03

  Stats: 57 lines in 2 files changed: 40 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971

PR: https://git.openjdk.org/jdk/pull/27971

From amenkov at openjdk.org  Tue Dec 23 19:59:05 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 19:59:05 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
In-Reply-To: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
Message-ID: <8jO_5ZBuZntbryhgJDID8t9BiwXpI78-h3UvXqLYmuI=.0636a3e1-7ad0-44ba-a742-da04643b5b4d@github.com>

On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
> 
> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
> 
> Testing:
>  - TBD: run mach5 tiers 1-6

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28965#pullrequestreview-3609181295

From kfarrell at openjdk.org  Tue Dec 23 20:07:36 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 20:07:36 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v5]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/7170aa06..d2e82895

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=03-04

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971

PR: https://git.openjdk.org/jdk/pull/27971

From kfarrell at openjdk.org  Tue Dec 23 20:11:21 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 20:11:21 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v5]
In-Reply-To: <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>
Message-ID: <Hj_WFgShmsZ-msBN45PNzfP7jgCCv2XnTbH57abYqT0=.5438f014-3b06-4554-a069-5b9eab07500c@github.com>

On Tue, 23 Dec 2025 20:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
>> 
>> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

50ms timed loop added to limit the proc file read for the AIX and linux implementations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3687847914

From kevinw at openjdk.org  Tue Dec 23 20:51:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 20:51:02 GMT
Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2]
In-Reply-To: <vxUs2URtHp12njet6DNzYUtcLHbp3nDupB5fckXiWvs=.e7c9430a-4a81-4b69-9314-8ebf94961f76@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
 <vxUs2URtHp12njet6DNzYUtcLHbp3nDupB5fckXiWvs=.e7c9430a-4a81-4b69-9314-8ebf94961f76@github.com>
Message-ID: <pr4j5etLfHiaNuL8ET-KURQEpYN_VOwxO05LK0MOK-k=.57e06ab3-0680-4999-83e9-479f08e35974@github.com>

On Tue, 23 Dec 2025 19:27:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Comment-only cleanup, didn't spot during previous review.
>> 
>> Trivial, no code affected.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Thanks Chris!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28962#issuecomment-3687923851

From kevinw at openjdk.org  Tue Dec 23 20:51:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 20:51:03 GMT
Subject: Integrated: 8374232: Comment cleanup in diagnosticCommand.cpp
In-Reply-To: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
References: <jMiCxRpkYG_ZEFb2r2hAJ9PgQalRXFp965lGeEw1B8U=.7b8485b5-5767-4b33-9ac9-8c42ee9af874@github.com>
Message-ID: <qJoomJB0hCrtWER1H6jjvtg7CzdiWfXaorfNH7vuvS8=.f46035ce-ea6b-489c-9448-082ee2b1ddef@github.com>

On Tue, 23 Dec 2025 09:47:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Comment-only cleanup, didn't spot during previous review.
> 
> Trivial, no code affected.

This pull request has now been integrated.

Changeset: 61cb6d74
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61cb6d740807f8ef356d88c0328d05be1a33a8c1
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8374232: Comment cleanup in diagnosticCommand.cpp

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/28962

From kevinw at openjdk.org  Tue Dec 23 21:37:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Dec 2025 21:37:00 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <59jhZwgqVGZRXR6bs5CSR7TqWIODblqBf1xtoqI0u4g=.1280299c-5607-408d-abff-79d86787d3f1@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

Just checked a new batch of 30 runs and hit one failure where it iterates 39 times and fails in vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java with "collectionCount not increased: 2346 -> 2346".

When 8373917 https://github.com/openjdk/jdk/pull/28876/files is integrated, the parsing of "-iterations=5"  will work, which cuts down the risk of failure further.

These tests are failing in CI so this change makes it better, and should go ahead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28923#issuecomment-3688024933

From amenkov at openjdk.org  Tue Dec 23 22:02:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 22:02:52 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v5]
In-Reply-To: <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
Message-ID: <DJ1FNQ4T7wpVS3riSvPn1fFRs6WJwh8eueE4NxKUvqI=.0360e0d5-d6a1-4fd5-8277-61d8f3d53b84@github.com>

On Tue, 23 Dec 2025 19:21:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update for MS warning 5287 fix

With the latest version GHA Windows-x64 build still fails:
debugInit.c
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184): error C2220: the following warning is treated as an error
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184): warning C5287: operands are different enum types '<unnamed-enum-JVMTI_VERSION_1>' and '<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to silence this warning
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186): warning C5287: operands are different enum types '<unnamed-enum-JVMTI_VERSION_1>' and '<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to silence this warning
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188): warning C5287: operands are different enum types '<unnamed-enum-JVMTI_VERSION_1>' and '<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to silence this warning
d:\a\jdk\jdk\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28937#issuecomment-3688076615

From sspitsyn at openjdk.org  Tue Dec 23 22:25:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Dec 2025 22:25:03 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
In-Reply-To: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
Message-ID: <ugBGcRAjT-c2L85xaasjyWB3klnCQer2N2qfLcXz_d4=.baa5b5a0-c8da-4010-a8e1-5729c8c285d7@github.com>

On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
> 
> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
> 
> Testing:
>  - TBD: run mach5 tiers 1-6

Chris and Alex, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28965#issuecomment-3688117415

From sspitsyn at openjdk.org  Tue Dec 23 22:25:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Dec 2025 22:25:04 GMT
Subject: Integrated: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
Message-ID: <-9c16Gg2MQ28f9y2sR-Qg5uTHWNx-W2kFB7fSnnPfGE=.02487445-5580-4e1e-bb13-f27a7d67ba00@github.com>

On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
> 
> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
> 
> Testing:
>  - TBD: run mach5 tiers 1-6

This pull request has now been integrated.

Changeset: f5249db9
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed

Reviewed-by: cjplummer, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/28965

From amenkov at openjdk.org  Tue Dec 23 22:25:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 22:25:57 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v5]
In-Reply-To: <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <kKiDeJrymQB84iV6yVi_neFDgyo1ec8_2b16NOK4i-M=.0ff184d6-4551-4343-b87b-45014f19109c@github.com>
Message-ID: <jGIUFBhEeVpti8OZ0bteKHSiGFIiF1TpG7swkc8pC8Y=.8f69d2c3-bc74-416b-bfc8-2e5d953f186c@github.com>

On Tue, 23 Dec 2025 19:21:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update for MS warning 5287 fix

Looks like this is a bug in MSVC: https://developercommunity.visualstudio.com/t/warning-C5287:-operands-are-different-e/10877942
cast to signed 32bit integer does not silence the warning.
I think the simplest would be to cast to unsigned int

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28937#issuecomment-3688120255

From amenkov at openjdk.org  Tue Dec 23 23:31:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 23:31:37 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v6]
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <Mw-SeU1O2QDJI7z4uItU45gnW4m57ZV4jJBkK878uYU=.eebbb32d-d832-4ff1-a789-7b4014df6984@github.com>

> The fix resolves disabled warnings in debugger agent

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  use unsigned int to workaround MS warning 5287

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28937/files
  - new: https://git.openjdk.org/jdk/pull/28937/files/64ca8bbb..30fbc50a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28937&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28937/head:pull/28937

PR: https://git.openjdk.org/jdk/pull/28937

From amenkov at openjdk.org  Wed Dec 24 01:24:09 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Dec 2025 01:24:09 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <REWGwHqqxZoelb8WFA54T1dS98vPx_OEtifcmILUF9E=.59e291df-03ee-40f2-9ca1-7d328b44d66a@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3609655483

From syan at openjdk.org  Wed Dec 24 01:41:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 01:41:12 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
In-Reply-To: <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
 <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
Message-ID: <Fy0p5AP3vwTCJoAuzj984U2p5xZeIlzjmSC_GX6douM=.92bb0e86-5674-4c06-acca-8588d6d301cf@github.com>

On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> However, the PR claims that these commits were all done on Nov 22, not Dec.

Sorry. I seted the wrong data/time to 2025-11 on mine local machine by mistake. This cause this strange phenomenon

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688364502

From serb at openjdk.org  Wed Dec 24 01:49:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 01:49:49 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where
 it was missed
Message-ID: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>

The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

-------------

Commit messages:
 - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28970/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374316
  Stats: 519 lines in 519 files changed: 0 ins; 0 del; 519 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From cjplummer at openjdk.org  Wed Dec 24 01:59:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Dec 2025 01:59:57 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v6]
In-Reply-To: <Mw-SeU1O2QDJI7z4uItU45gnW4m57ZV4jJBkK878uYU=.eebbb32d-d832-4ff1-a789-7b4014df6984@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <Mw-SeU1O2QDJI7z4uItU45gnW4m57ZV4jJBkK878uYU=.eebbb32d-d832-4ff1-a789-7b4014df6984@github.com>
Message-ID: <r1e6Bf2QzLQOZbXRLy970Kv1fAc7UsqmdPWGKEjoSkk=.a0b13a34-1348-463a-aab0-730d57323b8a@github.com>

On Tue, 23 Dec 2025 23:31:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use unsigned int to workaround MS warning 5287

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3609721506

From kbarrett at openjdk.org  Wed Dec 24 04:34:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 24 Dec 2025 04:34:53 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)

There are a lot of non-hotspot files in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688645543

From serb at openjdk.org  Wed Dec 24 04:52:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 04:52:58 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
Message-ID: <dBKMWCvfk1bUy0aCWJ7d6myTtQOQyg-kxA0whhThdYA=.e3f0e2a9-3f30-42ef-a48a-320f7308a133@github.com>

On Wed, 24 Dec 2025 04:32:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> There are a lot of non-hotspot files in this PR.

Most of them are related and were touched by the same commits pushed to `src/hotspot`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688672537

From serb at openjdk.org  Wed Dec 24 05:27:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 05:27:56 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <9cmIm_ANkhZ9knsjEEdCJjy4qJH6TGMFcLoPMS1OVBQ=.53c83270-52bb-4c26-a415-e54a9ed37f56@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I can split out some of these changes into a separate PR to make this one smaller, but I already have a bunch of them =(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688721427

From cjplummer at openjdk.org  Wed Dec 24 06:11:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Dec 2025 06:11:53 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <TAcOf3A0Mf0h3Yp5Yd5HYowUossPqxQl9qRbKewMzjQ=.9d52a257-3039-4df8-a3bf-f5afd95e389b@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3610020463

From sspitsyn at openjdk.org  Wed Dec 24 06:11:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Dec 2025 06:11:54 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <E5Nx0n9J0UFAHmqrKswFRZBs2eIQZuvAyLtVnPZcDyY=.87b1ba3b-e584-4e03-ba66-0300c1c3bc11@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Thank you for review, Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3688786608

From alanb at openjdk.org  Wed Dec 24 06:45:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Dec 2025 06:45:13 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
In-Reply-To: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
Message-ID: <TEch5W3hN73i5oHQlvmR25cAB5mnJC6Zcs-4EYMUQqY=.c80c8df0-9e17-40c4-8363-fe2e23f1be62@github.com>

On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
> 
> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
> 
> Testing:
>  - TBD: run mach5 tiers 1-6

src/hotspot/share/runtime/mountUnmountDisabler.hpp line 59:

> 57: 
> 58:  public:
> 59:   MountUnmountDisabler(bool exlusive = false);

In passing, exlusive -> exclusive

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28965#discussion_r2644936219

From syan at openjdk.org  Wed Dec 24 07:04:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:04:54 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v12]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <He5X9QVpKoacWYBQevbZ9N8XV6ZT0yRTaqTL43ndAFw=.f2c7349a-cf8c-4f60-a9f3-797d638585b4@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecesary System.gc() and add sleep 1s to wait unload event happen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6c144309..6fc4bb95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10-11

  Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Wed Dec 24 07:25:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:25:42 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v13]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <F67Pme6YGGdxPcgQZMezbApzktZht7Hp7leff4pWzps=.60e04bf1-a409-480b-82d5-e5ad87ef832e@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Move the "./bin" after vmekys to new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6fc4bb95..fc2e144d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11-12

  Stats: 44 lines in 22 files changed: 22 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Wed Dec 24 07:30:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:30:53 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
Message-ID: <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>

On Sat, 20 Dec 2025 04:55:02 GMT, SendaoYan <syan at openjdk.org> wrote:

> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews.

All the comments in touched tests has been checked.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688934784

From syan at openjdk.org  Wed Dec 24 08:15:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:15:39 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v14]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <6KN1kYB5JbzGX63M6tumdsgF435oXtobOFFVB39eWVg=.ca762d8a-f728-462b-9d69-ff2d10830883@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [x] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use WhiteBox.fulllGC() both for test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/fc2e144d..6610f776

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From syan at openjdk.org  Wed Dec 24 08:15:41 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:15:41 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
 <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>
Message-ID: <AlXVH55HuLs4eRx47t5HWJb4SN9F8jGuic_InqG20_E=.e99158a7-6c10-421c-8c13-936b6a065ec2@github.com>

On Mon, 22 Dec 2025 03:10:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It seems that, the references is non null at the first time. So it will not unload the classes actually,
>
> I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made.

I have changed the test always use WhiteBox.fullGC() instead of call unloadClass(). This test has been verified locally,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2645091951

From syan at openjdk.org  Wed Dec 24 08:22:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:22:58 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v15]
In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
Message-ID: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [x] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Change the copyright year from 2025 to 2026

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6610f776..f72866e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13-14

  Stats: 61 lines in 61 files changed: 0 ins; 0 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/28891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891

PR: https://git.openjdk.org/jdk/pull/28891

From sspitsyn at openjdk.org  Wed Dec 24 08:44:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Dec 2025 08:44:52 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <Gq8IeZvkqxL6TRoOM86OSgogX_l15itBPk6or54K0QA=.9d797b56-abf8-4205-ba87-fe69115fd5b6@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Thank you for review, Chris!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3689112049

From sspitsyn at openjdk.org  Wed Dec 24 08:50:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Dec 2025 08:50:04 GMT
Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread
 thread) is missed
In-Reply-To: <TEch5W3hN73i5oHQlvmR25cAB5mnJC6Zcs-4EYMUQqY=.c80c8df0-9e17-40c4-8363-fe2e23f1be62@github.com>
References: <eOf-r06fh-WqlP7HlC5k9TfJ235LkBLwXXxHHIMDdGI=.226d6899-08f6-408d-9cb3-6797d64e663a@github.com>
 <TEch5W3hN73i5oHQlvmR25cAB5mnJC6Zcs-4EYMUQqY=.c80c8df0-9e17-40c4-8363-fe2e23f1be62@github.com>
Message-ID: <_OzG6u0Cu6kUO4FJBU8hrntbHMbL28PQKZxj9WDhm70=.4072e357-2828-4fe1-b5ff-0d1e6249f3b9@github.com>

On Wed, 24 Dec 2025 06:41:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26.
>> This issue impacts JVM TI scalability. The  [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`.  It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing.
>> 
>> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`.
>> 
>> Testing:
>>  - TBD: run mach5 tiers 1-6
>
> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 59:
> 
>> 57: 
>> 58:  public:
>> 59:   MountUnmountDisabler(bool exlusive = false);
> 
> In passing, exlusive -> exclusive

Sorry, I've already integrated this PR and missed chance to correct line 59.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28965#discussion_r2645158235

From sspitsyn at openjdk.org  Wed Dec 24 08:53:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Dec 2025 08:53:21 GMT
Subject: RFR: 8374168: Resolve disabled warnings in JDWP agent [v6]
In-Reply-To: <Mw-SeU1O2QDJI7z4uItU45gnW4m57ZV4jJBkK878uYU=.eebbb32d-d832-4ff1-a789-7b4014df6984@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
 <Mw-SeU1O2QDJI7z4uItU45gnW4m57ZV4jJBkK878uYU=.eebbb32d-d832-4ff1-a789-7b4014df6984@github.com>
Message-ID: <Mhs53lK_x1BQ-v0M7wHwHqwN1wPJvbycDPFUOEwxEcg=.de454326-45d3-4745-b674-5fe6ad817893@github.com>

On Tue, 23 Dec 2025 23:31:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix resolves disabled warnings in debugger agent
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use unsigned int to workaround MS warning 5287

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28937#pullrequestreview-3610349065

From nbenalla at openjdk.org  Wed Dec 24 14:35:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 24 Dec 2025 14:35:53 GMT
Subject: RFR: 8374177: Update @since of HotSpotAOTCacheMXBean after
 JDK-8373607
In-Reply-To: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
References: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
Message-ID: <nOWyCdOKotctwjuDsA_R8cqbMYuZRsrT1csvEEx6LgI=.63357606-fd83-48ff-8651-c5ef5a3584c7@github.com>

On Sun, 21 Dec 2025 14:05:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

Thank you for the reviews; Alan and Ioi.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28944#issuecomment-3689941948

From nbenalla at openjdk.org  Wed Dec 24 14:41:25 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 24 Dec 2025 14:41:25 GMT
Subject: RFR: 8374177: Update @since of HotSpotAOTCacheMXBean after
 JDK-8373607 [v2]
In-Reply-To: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
References: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
Message-ID: <uhO7O7NjAHhToEALM0lUYWACV5y2SKP5_gZ4j1F8jrY=.47a0744a-d733-4b22-8a29-d79597de1d2d@github.com>

> Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28944/files
  - new: https://git.openjdk.org/jdk/pull/28944/files/02caf22f..02caf22f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28944&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28944&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28944/head:pull/28944

PR: https://git.openjdk.org/jdk/pull/28944

From nbenalla at openjdk.org  Wed Dec 24 14:41:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 24 Dec 2025 14:41:26 GMT
Subject: Integrated: 8374177: Update @since of HotSpotAOTCacheMXBean after
 JDK-8373607
In-Reply-To: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
References: <VnckWUSDmpU8HDzjMYQ6ouzZJfScrr8M_cfkdZ9kLWE=.4010d6c2-af59-45de-b92a-24ebca56ff96@github.com>
Message-ID: <gGhxwXuUzO5m5060eT3EE9fCyM2yH6wQEwb4FxMJzx0=.b319308d-5ea6-473f-9993-2de1e1b66592@github.com>

On Sun, 21 Dec 2025 14:05:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes to `HotSpotAOTCacheMXBean` have been backported to jdk 26, `@since` version needs to be updated to reflect that.

This pull request has now been integrated.

Changeset: 6ade3480
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ade34804f175b5dd1bf78515b78e5444d8be7f5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374177: Update @since of HotSpotAOTCacheMXBean after JDK-8373607

Reviewed-by: alanb, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/28944

From duke at openjdk.org  Wed Dec 24 23:47:12 2025
From: duke at openjdk.org (eunbin son)
Date: Wed, 24 Dec 2025 23:47:12 GMT
Subject: RFR: 8374341: Fix whitespace split in CoreUtils.getCoreFileLocation
Message-ID: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>

### Summary
Fix incorrect regex usage in CoreUtils.getCoreFileLocation.

### Description
CoreUtils.getCoreFileLocation uses String.split("\s", 2).
The string literal "\s" represents a backspace character, not a whitespace regex.
As a result, the split operation does not separate fields on whitespace.
This change replaces the pattern with "\\s+" to correctly split on whitespace.
No other logic is modified.

### Bug ID :  JDK-8374341 
https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341

-------------

Commit messages:
 - 8374341: Fix whitespace split in CoreUtils.getCoreFileLocation

Changes: https://git.openjdk.org/jdk/pull/28984/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374341
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28984/head:pull/28984

PR: https://git.openjdk.org/jdk/pull/28984

From duke at openjdk.org  Wed Dec 24 23:53:39 2025
From: duke at openjdk.org (eunbin son)
Date: Wed, 24 Dec 2025 23:53:39 GMT
Subject: RFR: 8374341: Fix whitespace split in
 CoreUtils.getCoreFileLocation [v2]
In-Reply-To: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
Message-ID: <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>

> ### Summary
> Fix incorrect regex usage in CoreUtils.getCoreFileLocation.
> 
> ### Description
> CoreUtils.getCoreFileLocation uses String.split("\s", 2).
> The string literal "\s" represents a backspace character, not a whitespace regex.
> As a result, the split operation does not separate fields on whitespace.
> This change replaces the pattern with "\\s+" to correctly split on whitespace.
> No other logic is modified.
> 
> ### Bug ID :  JDK-8374341 
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341

eunbin son has updated the pull request incrementally with one additional commit since the last revision:

  8374341: Update copyright year to 2025 for CoreUtils.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28984/files
  - new: https://git.openjdk.org/jdk/pull/28984/files/9f960957..a7596fa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28984/head:pull/28984

PR: https://git.openjdk.org/jdk/pull/28984

From lmesnik at openjdk.org  Thu Dec 25 05:18:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 25 Dec 2025 05:18:02 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <zXnm7tCVtXN0daBr0pfEvJkVzujOqP-MsvJomYwsju8=.e40f4c71-17d2-4c28-a07d-1ed81b843c6f@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3611860274

From syan at openjdk.org  Thu Dec 25 06:31:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 25 Dec 2025 06:31:02 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <0nb0Pv3hhk74FIN6RyixiHaY9MjDJBd59dZXxCyjZ_I=.8abe1774-f37d-4731-ae05-6bdeba799b61@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28923#pullrequestreview-3611908520

From serb at openjdk.org  Thu Dec 25 12:20:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 12:20:20 GMT
Subject: RFR: 8374358: Update copyright year to 2025 for test/hotspot in files
 where it was missed
Message-ID: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>

The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

-------------

Commit messages:
 - 8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28992/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28992&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374358
  Stats: 143 lines in 143 files changed: 0 ins; 0 del; 143 mod
  Patch: https://git.openjdk.org/jdk/pull/28992.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28992/head:pull/28992

PR: https://git.openjdk.org/jdk/pull/28992

From sspitsyn at openjdk.org  Thu Dec 25 23:59:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Dec 2025 23:59:03 GMT
Subject: [jdk26] RFR: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <Xe7YqfnTlz3NyYoFe3sL7QW2kY9tPhCmEy7zszFxMjU=.0b66f8b0-7444-4854-b529-17b6a05437bc@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

Thank you for review, Leonid!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3691828495

From sspitsyn at openjdk.org  Thu Dec 25 23:59:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Dec 2025 23:59:04 GMT
Subject: [jdk26] Integrated: 8374233: Overloaded constructor
 MountUnmountDisabler(jthread thread) is missed
In-Reply-To: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
References: <t5WwA91IRdQkpoVjOw_2ikHmcnwEl6i5hJ0rX72dQGM=.53b61fc4-6e87-4099-bf08-0fec2bca4e8d@github.com>
Message-ID: <hKPfJHxjVT9Ry6bL7DX-y4Ct9m5jxkj1v975W-IeHXE=.5432a859-9468-4275-ad0c-49c4b07bad22@github.com>

On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov).

This pull request has now been integrated.

Changeset: 646037dd
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/646037dd92bac5d3fec94c019830c010c86d101c
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed

Reviewed-by: amenkov, cjplummer, lmesnik
Backport-of: f5249db9c566f87f7fc4f3ed70114a8168babd8b

-------------

PR: https://git.openjdk.org/jdk/pull/28968

From serb at openjdk.org  Fri Dec 26 00:36:17 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 00:36:17 GMT
Subject: RFR: 8374361: Update copyright year to 2025 for jdk.hotspot.agent in
 files where it was missed
Message-ID: <UfHoj5-fDhPU7E3zmoFlD4YnLoByHQlJaJsxCXHndSo=.6a81906a-4c60-4414-8e56-8cd97fb8d609@github.com>

The copyright year in "jdk.hotspot.agent" files updated in 2025 has been bumped to 2025.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

-------------

Commit messages:
 - 8374361: Update copyright year to 2025 for jdk.hotspot.agent in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28994/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374361
  Stats: 18 lines in 18 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28994.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28994/head:pull/28994

PR: https://git.openjdk.org/jdk/pull/28994

From syan at openjdk.org  Fri Dec 26 02:24:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 26 Dec 2025 02:24:39 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable
Message-ID: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>

Hi all,

Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test.

Change has been verified locally. Test-fix only, no risk.

-------------

Commit messages:
 - 8374364: TestCgroupMetrics.java fails when docker service unavailable

Changes: https://git.openjdk.org/jdk/pull/28996/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374364
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

PR: https://git.openjdk.org/jdk/pull/28996

From jiefu at openjdk.org  Fri Dec 26 03:05:58 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 26 Dec 2025 03:05:58 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <YiFRWFACbtV0sDJ-Uc5u8Clkl0heKjK27bX8j8RVtmU=.d7d964f8-3acc-438e-a949-6a9cf11d70a1@github.com>

On Fri, 26 Dec 2025 02:17:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test.
> 
> Change has been verified locally. Test-fix only, no risk.

So `MetricsTester.main(args)` requires the docker service, right?

Maybe it would be better to add this check in a place like`MetricsTester`, where it requires docker service directly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3691978718

From serb at openjdk.org  Fri Dec 26 03:18:25 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 03:18:25 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>

The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.

**Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

-------------

Commit messages:
 - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28997/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374365
  Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/28997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28997/head:pull/28997

PR: https://git.openjdk.org/jdk/pull/28997

From syan at openjdk.org  Fri Dec 26 06:05:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 26 Dec 2025 06:05:49 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable
In-Reply-To: <YiFRWFACbtV0sDJ-Uc5u8Clkl0heKjK27bX8j8RVtmU=.d7d964f8-3acc-438e-a949-6a9cf11d70a1@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <YiFRWFACbtV0sDJ-Uc5u8Clkl0heKjK27bX8j8RVtmU=.d7d964f8-3acc-438e-a949-6a9cf11d70a1@github.com>
Message-ID: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com>

On Fri, 26 Dec 2025 03:02:56 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> So `MetricsTester.main(args)` requires the docker service, right?
> 
> Maybe it would be better to add this check in a place like`MetricsTester`, where it requires docker service directly.

Only jdk/internal/platform/cgroup/TestCgroupMetrics.java observed fails when docker service unavailable. There are total two tests invoke MetricsTester. The other test jdk/internal/platform/docker/TestSystemMetrics.java already call `DockerTestUtils.checkCanTestDocker()` [before start test](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java#L45). So i think it's better to leave this check inside test, same like to jdk/internal/platform/docker/TestSystemMetrics.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692198076

From jiefu at openjdk.org  Fri Dec 26 06:17:50 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 26 Dec 2025 06:17:50 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable
In-Reply-To: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <YiFRWFACbtV0sDJ-Uc5u8Clkl0heKjK27bX8j8RVtmU=.d7d964f8-3acc-438e-a949-6a9cf11d70a1@github.com>
 <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com>
Message-ID: <SWgVpoCtBtdCwUX6bmbNam1S77FWMaS7uDkoR-7aX4o=.0cad37d2-d8ef-4025-9059-1548c73dc912@github.com>

On Fri, 26 Dec 2025 06:02:09 GMT, SendaoYan <syan at openjdk.org> wrote:

> So i think it's better to leave this check inside test, same like to jdk/internal/platform/docker/TestSystemMetrics.java.

I don't think so.

Just imagine someone may call `MetricsTester.main(args)` again in the future, how can you prevent him/her not forgetting adding the check before the call?

That's why I would suggest adding it in the place where it requires docker directly, not the place indirectly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692221565

From syan at openjdk.org  Fri Dec 26 06:44:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 26 Dec 2025 06:44:38 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable [v2]
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <cTWPjeP9UlQRi3y69Uj2XLFQxMHkkBF0tNUslWPSxZc=.10f2e665-49b8-4864-8292-00d25c619e90@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test.
> 
> Change has been verified locally. Test-fix only, no risk.

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - Fix year
 - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28996/files
  - new: https://git.openjdk.org/jdk/pull/28996/files/9411a6e7..fe094b55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=00-01

  Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

PR: https://git.openjdk.org/jdk/pull/28996

From syan at openjdk.org  Fri Dec 26 06:44:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 26 Dec 2025 06:44:38 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable
In-Reply-To: <SWgVpoCtBtdCwUX6bmbNam1S77FWMaS7uDkoR-7aX4o=.0cad37d2-d8ef-4025-9059-1548c73dc912@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <YiFRWFACbtV0sDJ-Uc5u8Clkl0heKjK27bX8j8RVtmU=.d7d964f8-3acc-438e-a949-6a9cf11d70a1@github.com>
 <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com>
 <SWgVpoCtBtdCwUX6bmbNam1S77FWMaS7uDkoR-7aX4o=.0cad37d2-d8ef-4025-9059-1548c73dc912@github.com>
Message-ID: <oGsViJLzWLm5z6Dk4SueqYpeF5lAo3WW03EzGiFljgI=.a6d20d74-389e-467d-b5c4-f4abf08ccdb8@github.com>

On Fri, 26 Dec 2025 06:15:21 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> That's why I would suggest adding it in the place where it requires docker directly, not the place indirectly.

Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692264918

From jiefu at openjdk.org  Fri Dec 26 07:13:50 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 26 Dec 2025 07:13:50 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service
 unavailable [v2]
In-Reply-To: <cTWPjeP9UlQRi3y69Uj2XLFQxMHkkBF0tNUslWPSxZc=.10f2e665-49b8-4864-8292-00d25c619e90@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <cTWPjeP9UlQRi3y69Uj2XLFQxMHkkBF0tNUslWPSxZc=.10f2e665-49b8-4864-8292-00d25c619e90@github.com>
Message-ID: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com>

On Fri, 26 Dec 2025 06:44:38 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test.
>> 
>> Change has been verified locally. Test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix year
>  - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester

test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86:

> 84: 
> 85:     public static void main(String[] args) throws Exception {
> 86:         DockerTestUtils.checkCanTestDocker();

Thanks for the update.

Can you explain why here requires docker service directly?

>From the logs in JBS, I guess the places should be where the following docker files are required?

Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us
Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us
Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2647686625

From phh at openjdk.org  Fri Dec 26 22:58:54 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 22:58:54 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <I5ZJ3nhBTqj0rD4QaUxGPGkj7aymTjxki7HTtFrWCe8=.bd5028e4-e007-4dfe-8374-f2eb986cdc8a@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569

From phh at openjdk.org  Fri Dec 26 23:01:01 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 23:01:01 GMT
Subject: RFR: 8374361: Update copyright year to 2025 for jdk.hotspot.agent
 in files where it was missed
In-Reply-To: <UfHoj5-fDhPU7E3zmoFlD4YnLoByHQlJaJsxCXHndSo=.6a81906a-4c60-4414-8e56-8cd97fb8d609@github.com>
References: <UfHoj5-fDhPU7E3zmoFlD4YnLoByHQlJaJsxCXHndSo=.6a81906a-4c60-4414-8e56-8cd97fb8d609@github.com>
Message-ID: <iXzfA4b_8Ja_mYRbPiWkocSYeg62EGlNKL44fOFXfaU=.1ffcd81f-cd18-4056-b973-66836ad52cb5@github.com>

On Thu, 25 Dec 2025 23:54:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "jdk.hotspot.agent" files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28994#pullrequestreview-3613937520

From phh at openjdk.org  Fri Dec 26 23:03:12 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 23:03:12 GMT
Subject: RFR: 8374358: Update copyright year to 2025 for test/hotspot in
 files where it was missed
In-Reply-To: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
References: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
Message-ID: <ZLbQCiBp9hTnFWBN1seM1meM7HdqynWt6fP0trA0yCY=.cb22163e-f69d-4b51-acdc-4cda78d14b59@github.com>

On Thu, 25 Dec 2025 10:22:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28992#pullrequestreview-3613937892

From serb at openjdk.org  Sat Dec 27 04:59:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 04:59:00 GMT
Subject: Integrated: 8374358: Update copyright year to 2025 for test/hotspot in
 files where it was missed
In-Reply-To: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
References: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
Message-ID: <HY3T7G4sSRP25XxJylbgefpg2pUl9TW3uES9881veWc=.6f675961-cd4c-4533-ac28-f2666e4c3631@github.com>

On Thu, 25 Dec 2025 10:22:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 2886c3b6
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2886c3b68a8d4b098f7d093f0406d2a15e5910dc
Stats:     143 lines in 143 files changed: 0 ins; 0 del; 143 mod

8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Reviewed-by: phh

-------------

PR: https://git.openjdk.org/jdk/pull/28992

From serb at openjdk.org  Sat Dec 27 07:07:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:07:04 GMT
Subject: Integrated: 8374365: Update copyright year to 2025 for test/jdk in
 files where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <OVIzxn5wdIZIwLEH1aV5QOpA42bscvlkBnTJnCGxPcI=.1bf256e0-07ec-44a3-9090-79c3dad941e7@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 9512a43e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92
Stats:     76 lines in 76 files changed: 0 ins; 0 del; 76 mod

8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Reviewed-by: phh

-------------

PR: https://git.openjdk.org/jdk/pull/28997

From serb at openjdk.org  Sat Dec 27 07:30:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:30:59 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <xzvWxS1jF-8teyOrN4Mwd2J8Ws63QJ524glMUW_wQZg=.2db4c8bb-d713-4dbc-90c4-96fe8128c732@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137

From serb at openjdk.org  Sat Dec 27 07:40:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:40:58 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <weXDVzJ1NVeizP0nigye-yZwlOeGsXCvbYkOWOYffho=.8f7c44b3-def1-45c4-9cf7-e403355361a2@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693798808

From serb at openjdk.org  Sat Dec 27 08:27:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 08:27:48 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v2]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Sergey Bylokhov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8374316: Update copyright year to 2025 for hotspot in files where it was missed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/e4855247..12ba39f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00-01

  Stats: 222 lines in 222 files changed: 0 ins; 0 del; 222 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From duke at openjdk.org  Sat Dec 27 10:03:24 2025
From: duke at openjdk.org (eunbin son)
Date: Sat, 27 Dec 2025 10:03:24 GMT
Subject: RFR: 8374373: Correct typo in VirtualThreadSchedulerMXBean.java
 Javadoc
Message-ID: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>

### Summary
Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".

### Description
Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".

### Bug ID : JDK-8374373
https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373

-------------

Commit messages:
 - 8374373: Correct typo in VirtualThreadSchedulerMXBean.java Javadoc

Changes: https://git.openjdk.org/jdk/pull/29002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374373
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29002/head:pull/29002

PR: https://git.openjdk.org/jdk/pull/29002

From haraldei at openjdk.org  Sat Dec 27 11:32:06 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Sat, 27 Dec 2025 11:32:06 GMT
Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace
Message-ID: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>

The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living.

This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation.

As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace.

This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port.

This work was sponsored by The FreeBSD Foundation

-------------

Commit messages:
 - Move Hotspot Agent debugger for MacOSX

Changes: https://git.openjdk.org/jdk/pull/29003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374372
  Stats: 2364 lines in 28 files changed: 1167 ins; 1114 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/29003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29003/head:pull/29003

PR: https://git.openjdk.org/jdk/pull/29003

From serb at openjdk.org  Sun Dec 28 03:51:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:51:36 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v3]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <reSTecn5OEkbqIgLWkD5RgHZ90csOpnY1ygVh2AgHeY=.48ef324b-314b-4173-bcc0-05e7b224c068@github.com>

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Sergey Bylokhov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8374316: Update copyright year to 2025 for hotspot in files where it was missed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/12ba39f6..b8fe879e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=01-02

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From serb at openjdk.org  Sun Dec 28 03:51:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:51:36 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v2]
In-Reply-To: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>
Message-ID: <e-wx1xmlYWHuGNHrhF5TCYp8UmuR1ujFjl8gxVjGpAk=.8b314ef9-c3c1-4e45-9450-ec44c081045c@github.com>

On Sat, 27 Dec 2025 08:27:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `
>
> Sergey Bylokhov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8374316: Update copyright year to 2025 for hotspot in files where it was missed

I have to exclude files updated by this commit, since it was a copyright-only change:
JDK-8364597: Replace THL A29 Limited with Tencent
https://github.com/openjdk/jdk/commit/4c9eaddaef8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693857773

From serb at openjdk.org  Sun Dec 28 03:56:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:56:39 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into copy_hotspot
 - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/b8fe879e..5b29083f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=02-03

  Stats: 902 lines in 771 files changed: 32 ins; 91 del; 779 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From syan at openjdk.org  Mon Dec 29 08:38:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 29 Dec 2025 08:38:51 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted
 [v3]
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <_nWN7E-jJuR_2ZhDZdsSgfLWtlBpUI5R1qAxjOLx3yo=.eb153abc-a164-434e-96ac-4a892b79ac2f@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test.
> 
> Change has been verified locally. Test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Check cpu period and cpuset avaialable before test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28996/files
  - new: https://git.openjdk.org/jdk/pull/28996/files/fe094b55..1be8d17a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01-02

  Stats: 12 lines in 2 files changed: 7 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

PR: https://git.openjdk.org/jdk/pull/28996

From syan at openjdk.org  Mon Dec 29 08:40:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 29 Dec 2025 08:40:56 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted
 [v2]
In-Reply-To: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <cTWPjeP9UlQRi3y69Uj2XLFQxMHkkBF0tNUslWPSxZc=.10f2e665-49b8-4864-8292-00d25c619e90@github.com>
 <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com>
Message-ID: <Q3KZdOrdni4RrFFeNshcM1d4pWyj51pAdiB5BA0aCIc=.3008a0ed-f6fa-41eb-986c-aeb30c827e88@github.com>

On Fri, 26 Dec 2025 07:10:03 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix year
>>  - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester
>
> test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86:
> 
>> 84: 
>> 85:     public static void main(String[] args) throws Exception {
>> 86:         DockerTestUtils.checkCanTestDocker();
> 
> Thanks for the update.
> 
> Can you explain why here requires docker service directly?
> 
> From the logs in JBS, I guess the places should be where the following docker files are required?
> 
> Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us
> Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us
> Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat

I think this test fails because the cpuset in unmounted. So I updated the JBS titile and comments. And I added check 'cpu period' and 'cpu set' available or not before subtest, rather than check the docker service.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2650463886

From syan at openjdk.org  Mon Dec 29 08:48:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 29 Dec 2025 08:48:15 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted
 [v4]
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <JZ1XBqTKrhaFobCXf5S-S_Y5ecvQYEHsd_1iK0GhtdI=.07f6f29a-b45f-4b9d-aba9-1566540b30d0@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests.
> 
> Change has been verified locally. Test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28996/files
  - new: https://git.openjdk.org/jdk/pull/28996/files/1be8d17a..068b1591

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

PR: https://git.openjdk.org/jdk/pull/28996

From kbarrett at openjdk.org  Mon Dec 29 09:40:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 29 Dec 2025 09:40:59 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <SWOIaRxamByT07rEjKFqGRa7HPMyPncj4I39NcE6P8Q=.0a36484d-8ee3-4ff1-ab6a-f8ae54e986dc@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28970#pullrequestreview-3615459136

From alanb at openjdk.org  Mon Dec 29 12:44:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Dec 2025 12:44:59 GMT
Subject: RFR: 8374373: Correct typo in VirtualThreadSchedulerMXBean.java
 Javadoc
In-Reply-To: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
Message-ID: <nk0igkVACmVGpFLxXsd07Vg03ksH2LWCuaUgcV_bgXk=.69cbd543-8c65-439e-87a4-6f4d08d10e36@github.com>

On Sat, 27 Dec 2025 09:55:58 GMT, eunbin son <duke at openjdk.org> wrote:

> ### Summary
> Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".
> 
> ### Description
> Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".
> 
> ### Bug ID : JDK-8374373
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373

The change is okay. Can you update the PR title to align with the JBS issue?

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29002#pullrequestreview-3615791502

From duke at openjdk.org  Mon Dec 29 13:36:55 2025
From: duke at openjdk.org (eunbin son)
Date: Mon, 29 Dec 2025 13:36:55 GMT
Subject: RFR: 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism
 javadoc [v2]
In-Reply-To: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
Message-ID: <A8d_bxtNccIlvcrg09CBbtm78Fy0CI9YBPcdoCdzBbQ=.e15052c0-7575-4aee-9244-80d53d88a7fd@github.com>

> ### Summary
> Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".
> 
> ### Description
> Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".
> 
> ### Bug ID : JDK-8374373
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373

eunbin son has updated the pull request incrementally with two additional commits since the last revision:

 - Update full name
 - Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29002/files
  - new: https://git.openjdk.org/jdk/pull/29002/files/65006499..410b5e3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29002&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29002&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29002/head:pull/29002

PR: https://git.openjdk.org/jdk/pull/29002

From duke at openjdk.org  Mon Dec 29 13:36:56 2025
From: duke at openjdk.org (eunbin son)
Date: Mon, 29 Dec 2025 13:36:56 GMT
Subject: RFR: 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism
 javadoc [v2]
In-Reply-To: <nk0igkVACmVGpFLxXsd07Vg03ksH2LWCuaUgcV_bgXk=.69cbd543-8c65-439e-87a4-6f4d08d10e36@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
 <nk0igkVACmVGpFLxXsd07Vg03ksH2LWCuaUgcV_bgXk=.69cbd543-8c65-439e-87a4-6f4d08d10e36@github.com>
Message-ID: <SWMdc6rTms_0VOXRHxpVtL-R88ZkfvLpftoT6ccBq3c=.c221d30a-388c-40e8-841b-3ca83a73af87@github.com>

On Mon, 29 Dec 2025 12:41:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> eunbin son has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update full name
>>  - Update full name
>
> The change is okay. Can you update the PR title to align with the JBS issue?

@AlanBateman Thanks for the review.

I?ve updated the PR title to match the JBS issue title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29002#issuecomment-3696537556

From serb at openjdk.org  Mon Dec 29 21:24:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 29 Dec 2025 21:24:13 GMT
Subject: Integrated: 8374361: Update copyright year to 2025 for
 jdk.hotspot.agent in files where it was missed
In-Reply-To: <UfHoj5-fDhPU7E3zmoFlD4YnLoByHQlJaJsxCXHndSo=.6a81906a-4c60-4414-8e56-8cd97fb8d609@github.com>
References: <UfHoj5-fDhPU7E3zmoFlD4YnLoByHQlJaJsxCXHndSo=.6a81906a-4c60-4414-8e56-8cd97fb8d609@github.com>
Message-ID: <A4FzhzDKvYpEpnsb5M7nGk84EVWWVqmyuSSBprqqg6o=.c46bda3f-2d98-4ef4-a55b-63eeee45c0c4@github.com>

On Thu, 25 Dec 2025 23:54:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "jdk.hotspot.agent" files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 92c6799b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92c6799b401eb786949e88cd7142002b2a875ce0
Stats:     18 lines in 18 files changed: 0 ins; 0 del; 18 mod

8374361: Update copyright year to 2025 for jdk.hotspot.agent in files where it was missed

Reviewed-by: phh

-------------

PR: https://git.openjdk.org/jdk/pull/28994

From serb at openjdk.org  Tue Dec 30 12:12:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 12:12:07 GMT
Subject: Integrated: 8374316: Update copyright year to 2025 for hotspot in
 files where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <q5hguWA8JeDeU31OPzwGDT_V4BGx65-hGRIFqYTHdSM=.a1e57a7d-48e6-421e-ab1e-37fbdc54be02@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: a6462d64
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6462d641cba004829f9136df22f3d953c0e0c5d
Stats:     451 lines in 451 files changed: 0 ins; 0 del; 451 mod

8374316: Update copyright year to 2025 for hotspot in files where it was missed

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/28970

From serb at openjdk.org  Tue Dec 30 12:34:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 12:34:15 GMT
Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files
 under test/ where it was missed
Message-ID: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>

The copyright year in test/* files updated in 2025 has been bumped to 2025.

Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

-------------

Commit messages:
 - revert langtools/jdk/javadoc/doclet/testSourceTab/SingleTab
 - 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed.

Changes: https://git.openjdk.org/jdk/pull/29006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374383
  Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/29006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29006/head:pull/29006

PR: https://git.openjdk.org/jdk/pull/29006

From lmesnik at openjdk.org  Tue Dec 30 19:04:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Dec 2025 19:04:57 GMT
Subject: RFR: 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring:
 -iterations setting misused in tests
In-Reply-To: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
References: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
Message-ID: <XsDL1WeC7YMSBIPRcjHRiTKVn_58BrHLnptAv3Drsxw=.6289275e-1373-471a-8188-a8138a87e439@github.com>

On Wed, 17 Dec 2025 18:27:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Some tests in test/hotspot/jtreg/vmTestbase/nsk tests are misusing the -iterations command-line option:  it is parsed only as "-iterations x" rather than "-iterations=x"
> 
> Fixing the RunParams parsing to recognise this saves updating multiple tests.
> 
> Other options are "option=value" so accepting -iterations=number is what we might expect (and is what tests are currently written to use).
> 
> The change makes logs look correct.  No more "Iterations: 0".
> 
> There are tests that currently log "Iterations: 0" but still do some work, so this is partly cosmetic, but also if you were thinking of making a test do some set limited number of iterations, you can now follow the example of other tests and have it work.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28876#pullrequestreview-3619034707

From lmesnik at openjdk.org  Tue Dec 30 19:26:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Dec 2025 19:26:57 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v2]
In-Reply-To: <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>
Message-ID: <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com>

On Thu, 18 Dec 2025 20:29:38 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Require load and unload events
>  - Revert "Fix NMethodRelocationTest"
>    
>    This reverts commit dae91d8d12820c94c2c412f3e84935072e572595.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 60:

> 58:                 "--enable-native-access=ALL-UNNAMED",
> 59:                 "-Xbootclasspath/a:.",
> 60:                 "-Xbatch",

I think that
 "-XX:+UseSerialGC",
might be removed
The WB.fullGC() should works for any GC.
As I know, createTestJavaProcessBuilder() propagate all VM arguments to forked process. So not clear how it works now.

test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 188:

> 186:         WHITE_BOX.deoptimizeAll();
> 187: 
> 188:         while (true) {

It would be better to have some variable that is set in 'callbackCompiledMethodUnload' to sync exit.
I think that it is more reliable then using stdout for this (even with flushing). 
However, it might be fixed later, if we find any issues with current version.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3619074331
PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2653705691
PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2653690321

From serb at openjdk.org  Tue Dec 30 20:18:34 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 20:18:34 GMT
Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining files
 under src/ where it was missed
Message-ID: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>

The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

-------------

Commit messages:
 - 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Changes: https://git.openjdk.org/jdk/pull/29008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374391
  Stats: 89 lines in 89 files changed: 0 ins; 0 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/29008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29008/head:pull/29008

PR: https://git.openjdk.org/jdk/pull/29008

From duke at openjdk.org  Tue Dec 30 22:45:24 2025
From: duke at openjdk.org (eunbin son)
Date: Tue, 30 Dec 2025 22:45:24 GMT
Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor
 error messages for better clarity
Message-ID: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>

### Summary
MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)".

This addresses the first of three issues in JDK-8374395.

### Description
When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this.

toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged.

Added test cases to the existing jtreg test file. All tests pass.

Bug-ID : JDK-8374395 
https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395

-------------

Commit messages:
 - Update full name
 - 8374395: Clarify undefined values in MemoryUsage.toString()

Changes: https://git.openjdk.org/jdk/pull/29009/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374395
  Stats: 100 lines in 2 files changed: 96 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29009/head:pull/29009

PR: https://git.openjdk.org/jdk/pull/29009

From duke at openjdk.org  Tue Dec 30 23:13:21 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 30 Dec 2025 23:13:21 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v3]
In-Reply-To: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <MYeXTzG-jNUeamIHyvp_taSSMaMo2-3EeuAhINx3k1Q=.c5d9f131-1398-4fb2-a240-15238083fcc1@github.com>

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.

Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:

  Move validation logic to agent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28683/files
  - new: https://git.openjdk.org/jdk/pull/28683/files/d1577f8e..cc926342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=01-02

  Stats: 137 lines in 2 files changed: 46 ins; 76 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28683/head:pull/28683

PR: https://git.openjdk.org/jdk/pull/28683

From duke at openjdk.org  Tue Dec 30 23:20:34 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 30 Dec 2025 23:20:34 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v4]
In-Reply-To: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <raBeTodEerDMJRLWrBLiyNCSPp-EnUdRNa1spfIHM7c=.04366a92-6294-4821-84d2-f865da770ec0@github.com>

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.

Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:

  Add check for different addresses

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28683/files
  - new: https://git.openjdk.org/jdk/pull/28683/files/cc926342..cd023c3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=02-03

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28683/head:pull/28683

PR: https://git.openjdk.org/jdk/pull/28683

From duke at openjdk.org  Tue Dec 30 23:20:35 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 30 Dec 2025 23:20:35 GMT
Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not
 published before JVM exit [v2]
In-Reply-To: <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>
 <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com>
Message-ID: <dYqSZwnLj2EXNKrVEjVB8JXdnzYyWMButTkfouxLmno=.b67a3ca9-06c0-402e-9e95-a288993adda3@github.com>

On Tue, 30 Dec 2025 19:17:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Require load and unload events
>>  - Revert "Fix NMethodRelocationTest"
>>    
>>    This reverts commit dae91d8d12820c94c2c412f3e84935072e572595.
>
> test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 188:
> 
>> 186:         WHITE_BOX.deoptimizeAll();
>> 187: 
>> 188:         while (true) {
> 
> It would be better to have some variable that is set in 'callbackCompiledMethodUnload' to sync exit.
> I think that it is more reliable then using stdout for this (even with flushing). 
> However, it might be fixed later, if we find any issues with current version.

I agree I don't think we should rely on stdout. I updated the test so all the event checking happens in the agent, and I kept some of the logging for debugging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2654280547

From jpai at openjdk.org  Wed Dec 31 04:52:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Dec 2025 04:52:50 GMT
Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining
 files under test/ where it was missed
In-Reply-To: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
References: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
Message-ID: <sXn8IoB2J5s7x3sF5ftW_adbPW8LxaZ_p0nWfgu2BsY=.f9752b40-934c-4c08-ab30-1f248d0c455e@github.com>

On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in test/* files updated in 2025 has been bumped to 2025.
> 
> Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Looks OK to me. I did a trivial verification that the files updated in this PR were indeed updated in 2025.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29006#pullrequestreview-3620246101

From alanb at openjdk.org  Wed Dec 31 07:59:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Dec 2025 07:59:53 GMT
Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor
 error messages for better clarity
In-Reply-To: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
References: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
Message-ID: <s4Hl88Z-XrD3lJ40veF6cI_lSldxJLBnDdDksV915VE=.7d2f46df-666a-4f16-8d4a-d1250b0e8d71@github.com>

On Tue, 30 Dec 2025 22:37:43 GMT, Eunbin Son <duke at openjdk.org> wrote:

> This addresses the first of three issues in JDK-8374395.

Note that you can't use the same JBS issue for different PRs/commits. If there are other changes proposed then they will need their own JBS issues.

test/jdk/java/lang/management/MemoryUsage would be a better place for unit tests for this API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29009#issuecomment-3701660168

From duke at openjdk.org  Wed Dec 31 09:04:52 2025
From: duke at openjdk.org (duke)
Date: Wed, 31 Dec 2025 09:04:52 GMT
Subject: RFR: 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism
 javadoc [v2]
In-Reply-To: <A8d_bxtNccIlvcrg09CBbtm78Fy0CI9YBPcdoCdzBbQ=.e15052c0-7575-4aee-9244-80d53d88a7fd@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
 <A8d_bxtNccIlvcrg09CBbtm78Fy0CI9YBPcdoCdzBbQ=.e15052c0-7575-4aee-9244-80d53d88a7fd@github.com>
Message-ID: <fizGs9EpU015tmoKvVkC2xUe0u_UY0ZkDKvFzll6z7M=.778061b3-91a5-437f-b057-ca7d9038faec@github.com>

On Mon, 29 Dec 2025 13:36:55 GMT, Eunbin Son <duke at openjdk.org> wrote:

>> ### Summary
>> Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".
>> 
>> ### Description
>> Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".
>> 
>> ### Bug ID : JDK-8374373
>> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373
>
> Eunbin Son has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update full name
>  - Update full name

@thswlsqls 
Your change (at version 410b5e3b2d9bcbf328545116087713fded7ca60e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29002#issuecomment-3701782501

From duke at openjdk.org  Wed Dec 31 09:38:10 2025
From: duke at openjdk.org (Eunbin Son)
Date: Wed, 31 Dec 2025 09:38:10 GMT
Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor
 error messages for better clarity [v2]
In-Reply-To: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
References: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
Message-ID: <pklMzpwxKW6M71-RO15sUlE3Z-4r5n16H80mCBFAhb0=.8c6a88ee-ba99-46ac-9a5e-78ca28fb38b2@github.com>

> ### Summary
> MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)".
> 
> This addresses the first of three issues in JDK-8374395.
> 
> ### Description
> When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this.
> 
> toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged.
> 
> Added test cases to the existing jtreg test file. All tests pass.
> 
> ### Bug-ID : JDK-8374395 
> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395

Eunbin Son has updated the pull request incrementally with one additional commit since the last revision:

  8374395: Add JUnit test for MemoryUsage.toString() undefined values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29009/files
  - new: https://git.openjdk.org/jdk/pull/29009/files/479857d0..413e3c12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29009&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29009&range=00-01

  Stats: 175 lines in 2 files changed: 87 ins; 88 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29009/head:pull/29009

PR: https://git.openjdk.org/jdk/pull/29009

From duke at openjdk.org  Wed Dec 31 09:40:03 2025
From: duke at openjdk.org (Eunbin Son)
Date: Wed, 31 Dec 2025 09:40:03 GMT
Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor
 error messages for better clarity
In-Reply-To: <s4Hl88Z-XrD3lJ40veF6cI_lSldxJLBnDdDksV915VE=.7d2f46df-666a-4f16-8d4a-d1250b0e8d71@github.com>
References: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
 <s4Hl88Z-XrD3lJ40veF6cI_lSldxJLBnDdDksV915VE=.7d2f46df-666a-4f16-8d4a-d1250b0e8d71@github.com>
Message-ID: <KTuL0cnHWrby39kaEJ9Cf5jkMrOwcAVAD2Xg600bdTs=.b54e9eb9-538b-4fc0-aeec-e22917bff3b5@github.com>

On Wed, 31 Dec 2025 07:57:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ### Summary
>> MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)".
>> 
>> This addresses the first of three issues in JDK-8374395.
>> 
>> ### Description
>> When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this.
>> 
>> toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged.
>> 
>> Added test cases to the existing jtreg test file. All tests pass.
>> 
>> ### Bug-ID : JDK-8374395 
>> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395
>
>> This addresses the first of three issues in JDK-8374395.
> 
> Note that you can't use the same JBS issue for different PRs/commits. If there are other changes proposed then they will need their own JBS issues.
> 
> test/jdk/java/lang/management/MemoryUsage would be a better place for unit tests for this API.

@AlanBateman Thanks for the review. Addressed. 

This PR covers only the first issue from JDK-8374395. 
Should I create separate JBS issues for the remaining two?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29009#issuecomment-3701837689

From serb at openjdk.org  Wed Dec 31 10:09:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 10:09:05 GMT
Subject: Integrated: 8374383: Update the copyright year to 2025 in the
 remaining files under test/ where it was missed
In-Reply-To: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
References: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
Message-ID: <smEHY8cgLh9-M18FFY97LLhNXwzDzE76Nt3pOopNIS8=.b4647ee0-2703-4bd5-a34a-06b114087b2f@github.com>

On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in test/* files updated in 2025 has been bumped to 2025.
> 
> Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: c6246d58
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6246d58f72942b66cb0632186366f0b99402306
Stats:     76 lines in 76 files changed: 0 ins; 0 del; 76 mod

8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/29006

From aivanov at openjdk.org  Wed Dec 31 15:35:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 31 Dec 2025 15:35:53 GMT
Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining
 files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <qgHsAf6PG9vbKvWMtLS8qMjDZaiHK38XZseoMcctP1s=.af0a3852-bbf5-43cf-b615-5188ce2a29e0@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29008#pullrequestreview-3621060611

From kevinw at openjdk.org  Wed Dec 31 15:53:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Dec 2025 15:53:12 GMT
Subject: RFR: 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring:
 -iterations setting misused in tests
In-Reply-To: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
References: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
Message-ID: <blhIITWw7FfbyEOUC72lktjFftHWBcVJ2GsEEYqFuwE=.c95e5632-03ee-419c-a14d-39e7a5cfa61d@github.com>

On Wed, 17 Dec 2025 18:27:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Some tests in test/hotspot/jtreg/vmTestbase/nsk tests are misusing the -iterations command-line option:  it is parsed only as "-iterations x" rather than "-iterations=x"
> 
> Fixing the RunParams parsing to recognise this saves updating multiple tests.
> 
> Other options are "option=value" so accepting -iterations=number is what we might expect (and is what tests are currently written to use).
> 
> The change makes logs look correct.  No more "Iterations: 0".
> 
> There are tests that currently log "Iterations: 0" but still do some work, so this is partly cosmetic, but also if you were thinking of making a test do some set limited number of iterations, you can now follow the example of other tests and have it work.

Thanks Leonid!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28876#issuecomment-3702420444

From kevinw at openjdk.org  Wed Dec 31 15:53:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Dec 2025 15:53:12 GMT
Subject: Integrated: 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring:
 -iterations setting misused in tests
In-Reply-To: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
References: <W6RBpl8FukPBC-gm_WVXB9cDnnqfOtnHAPg6Ix7zJeY=.39f1f3aa-2189-426f-803d-189805a6589a@github.com>
Message-ID: <dkO7KZ0N4i9xoey9vgNOQKkBv6aZ2WuxKP5zvHFgxb4=.c9141d82-b767-47e1-8ae3-885224d00b9f@github.com>

On Wed, 17 Dec 2025 18:27:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Some tests in test/hotspot/jtreg/vmTestbase/nsk tests are misusing the -iterations command-line option:  it is parsed only as "-iterations x" rather than "-iterations=x"
> 
> Fixing the RunParams parsing to recognise this saves updating multiple tests.
> 
> Other options are "option=value" so accepting -iterations=number is what we might expect (and is what tests are currently written to use).
> 
> The change makes logs look correct.  No more "Iterations: 0".
> 
> There are tests that currently log "Iterations: 0" but still do some work, so this is partly cosmetic, but also if you were thinking of making a test do some set limited number of iterations, you can now follow the example of other tests and have it work.

This pull request has now been integrated.

Changeset: 97f4f003
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97f4f003f4de19596de7f3d40295506edaaa30af
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring: -iterations setting misused in tests

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/28876

From kevinw at openjdk.org  Wed Dec 31 16:29:09 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Dec 2025 16:29:09 GMT
Subject: RFR: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <lZBU9Q49NqxVveIwutO-j4e1uHBgNcqSRilSuuq9QHk=.c4768c11-b69e-40f8-82e4-8639da754697@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

Thanks Chris and Sendao!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28923#issuecomment-3702467965

From kevinw at openjdk.org  Wed Dec 31 16:29:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Dec 2025 16:29:10 GMT
Subject: Integrated: 8373642: Test
 vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
 failed
In-Reply-To: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
References: <eUEux19wTUTjapVu0RHejhfe13aSAbOVkWPanj2MSpM=.049d13c7-21c4-4a8b-93d2-3ee667d317d8@github.com>
Message-ID: <EBdMKfot49aMi6zah3AplgEz6zdXMF-2jW69XeKfvIk=.68770f11-51ee-438a-befd-d916e09dd08a@github.com>

On Fri, 19 Dec 2025 11:18:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> In JDK-8370731 I made this test much too thorough.  It was good to ensure some testing was always done, but fixing the existing loop within runOne() was wrong.  We have an outer loop already in the run() method.
> 
> 20, 30 or 137 (!) iterations is unnecessary.  Eventually or occasionally an iteration does not cause a collection.
> Limiting to 5 iterations.
> 
> This depends on the change in https://github.com/openjdk/jdk/pull/28876/files to use "-iterations=" consistently like (a few) other tests.
> 
> Tests that do some allocation and check for a collection can be unreliable.
> This may also benefit from what is proposed in https://github.com/openjdk/jdk/pull/28891
> 
> I'd like to get this change in though, as the test may fail more now than before.

This pull request has now been integrated.

Changeset: a1a75ab6
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1a75ab6d1ca25fc88be75239670f5a011ea3053
Stats:     23 lines in 5 files changed: 7 ins; 5 del; 11 mod

8373642: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java failed

Reviewed-by: cjplummer, syan

-------------

PR: https://git.openjdk.org/jdk/pull/28923

From serb at openjdk.org  Wed Dec 31 17:20:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 17:20:09 GMT
Subject: Integrated: 8374391: Update the copyright year to 2025 in the
 remaining files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <F4AV_5qECl59yK4xOpwJv_zZJNk6uucZ2aQ1a8KRTrQ=.bf5679eb-75e2-474d-ad7a-8858342202b2@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 2d1be8a9
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f
Stats:     89 lines in 89 files changed: 0 ins; 0 del; 89 mod

8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/29008