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