From amenkov at openjdk.org  Wed May  1 00:20:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 1 May 2024 00:20:52 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v3]
In-Reply-To: <U14JnG2n1JtunonMxDYtGQq-_PpZf-RfosBEbLteP1E=.471d3d9a-9bb9-4fbe-8366-a54b32af5846@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <zJDP5yOYfBRaNXFcNaxW7grk5cA_ry_ZTEnE3a2YNyg=.64f9ace6-db9e-42b5-af81-ed7acac2269c@github.com>
 <SREtir9aP4YOBYbn6pXv-d2Mt9JA20_g9bL0WeTKMys=.7f9b8413-0689-4820-a2f0-871692fd51ee@github.com>
 <U14JnG2n1JtunonMxDYtGQq-_PpZf-RfosBEbLteP1E=.471d3d9a-9bb9-4fbe-8366-a54b32af5846@github.com>
Message-ID: <LUlNlRZfC4VE6zYVp3-jup5a6idhX_fV71U6EeGVXBg=.6cbe672f-27d8-41f5-bc15-2c08b4cc2dd8@github.com>

On Tue, 30 Apr 2024 02:05:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Looks like in JVMTI `current_thread` is more common (and `current` is usually used in runtime :)
>
> The plan is to unify this with the approach used by the Runtime team.

Replaced all touched "current_thread" and "calling_thread" with "current"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18986#discussion_r1585718011

From sspitsyn at openjdk.org  Wed May  1 08:43:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 08:43:59 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v3]
In-Reply-To: <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
Message-ID: <-p7pqoYebg7hw2X1zB4TKN_xf6L0ZAaKA1uB8ajkPDo=.9620a1b6-49cc-4545-86ae-94d1c10d7596@github.com>

On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
>> For performance analysis, experiments and numbers, please, see the comment below this description.
>> 
>> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>> 
>> Testing:
>>  - Tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct comments related to VTMS transition counters

Alex and Chris, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18937#issuecomment-2088158954

From sspitsyn at openjdk.org  Wed May  1 08:44:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 08:44:00 GMT
Subject: Integrated: 8330969: scalability issue with loaded JVMTI agent
In-Reply-To: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
Message-ID: <ekB0wLuBMrR_ZH58IgMaqpDkiVc-8j0FE8-gJ86r-7M=.897d79eb-9835-4012-b132-aa46334e89f9@github.com>

On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
> For performance analysis, experiments and numbers, please, see the comment below this description.
> 
> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
> 
> Testing:
>  - Tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 663acd2e
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/663acd2e173114fec7c2f50084af9ec56150d394
Stats:     42 lines in 5 files changed: 14 ins; 11 del; 17 mod

8330969: scalability issue with loaded JVMTI agent

Reviewed-by: amenkov, cjplummer

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

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

From sspitsyn at openjdk.org  Wed May  1 12:33:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 12:33:08 GMT
Subject: RFR: 8328083: degrade virtual thread support for GetObjectMonitorUsage
Message-ID: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>

The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.

The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.

`GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.

One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.

The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.

Also, please, review the related CSR and Release Note:
- CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
- RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage

Testing:
 - tested impacted and updated tests locally
 - tested with mach5 tiers 1-6

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

Commit messages:
 - fix trailing space in one test
 - 8328083: degrade virtual thread support for GetObjectMonitorUsage

Changes: https://git.openjdk.org/jdk/pull/19030/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328083
  Stats: 156 lines in 12 files changed: 102 ins; 2 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/19030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19030/head:pull/19030

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

From syan at openjdk.org  Wed May  1 15:02:59 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 1 May 2024 15:02:59 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64
Message-ID: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>

Hi,
  GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. This testcase should be problemlist.

  Only change the ProblemList, no risk.

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

Commit messages:
 - 8331466: Problemlist serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64

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

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

From duke at openjdk.org  Wed May  1 17:32:59 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 1 May 2024 17:32:59 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
Message-ID: <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>

On Tue, 30 Jan 2024 12:13:05 GMT, Per Lundberg <duke at openjdk.org> wrote:

>> 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 217:
> 
>> 215:         // Instead, attach relative to the target root filesystem as exposed by
>> 216:         // procfs regardless of namespaces.
>> 217:         String root = "/proc/" + pid + "/root/" + tmpdir;
> 
> Helping myself and other future readers understand this: the problem with the previous implementation is that the code _assumed_ that the tmpdir could be accessed this way (`/proc/<pid>/root/<tmpdir>`). In other words:
> 
> * The code for creating the socket would correctly check if `pid != ns_pid` and then act accordingly (`/proc/<pid>/root/<tmpdir>` or just plain `<tmpdir>`)
> * The code for reading the socket would not have the check the above. It would resort to always use `/proc/<pid>/root/<tmpdir>`.
> * For certain scenarios (`CAP_NET_BIND_SERVICE`-processes, as described in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081), we would get a `Permission denied` when trying to access the temporary directory like this.
> 
> What this PR does is to ensure that the same `pid != ns_pid` check is used both when creating and reading the socket, and fall back to `<tmpdir>` when no namespacing is being used. This seems to work better for these processes with elevated permissions.

should it not be comparing pid namespace ids and not pids?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1586542476

From duke at openjdk.org  Wed May  1 17:51:01 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 1 May 2024 17:51:01 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
 <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>
Message-ID: <HM17i93lm8bIFW2iM3DSef3c5z3kMZ5i3lg-J6o2eyQ=.35252f4e-2516-4773-bfb1-41feb61d5c68@github.com>

On Wed, 1 May 2024 17:30:05 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 217:
>> 
>>> 215:         // Instead, attach relative to the target root filesystem as exposed by
>>> 216:         // procfs regardless of namespaces.
>>> 217:         String root = "/proc/" + pid + "/root/" + tmpdir;
>> 
>> Helping myself and other future readers understand this: the problem with the previous implementation is that the code _assumed_ that the tmpdir could be accessed this way (`/proc/<pid>/root/<tmpdir>`). In other words:
>> 
>> * The code for creating the socket would correctly check if `pid != ns_pid` and then act accordingly (`/proc/<pid>/root/<tmpdir>` or just plain `<tmpdir>`)
>> * The code for reading the socket would not have the check the above. It would resort to always use `/proc/<pid>/root/<tmpdir>`.
>> * For certain scenarios (`CAP_NET_BIND_SERVICE`-processes, as described in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081), we would get a `Permission denied` when trying to access the temporary directory like this.
>> 
>> What this PR does is to ensure that the same `pid != ns_pid` check is used both when creating and reading the socket, and fall back to `<tmpdir>` when no namespacing is being used. This seems to work better for these processes with elevated permissions.
>
> should it not be comparing pid namespace ids and not pids?

Do you mean that it should compare the input PID against the outermost (leftmost) PID in the `NSpid` list from `/proc/<pid>/status` and not innermost (rightmost) as is done right now? What would be the benefit of that? Or did you mean something else?

I'm working on a fix for https://bugs.openjdk.org/browse/JDK-8327114 right now, and it occurred to me that there is a tiny risk of `pid != ns_pid` not evaluating to `true` even though the processes are in different PID namespaces (because two different PID namespaces can have the same PIDs). I think it could be mitigated by always trying `/proc/<pid>/root/tmp` first, and if it cannot be read, fall back to `/tmp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1586563442

From amenkov at openjdk.org  Wed May  1 18:06:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 1 May 2024 18:06:04 GMT
Subject: Integrated: 8322043: HeapDumper should use parallel dump by default
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <WUGMefagETaJhpFOMGr-bohj_EDUnoYLctngLTavWbg=.6dc2616c-dc11-40c5-a24f-bcb5ba87db1a@github.com>

On Fri, 12 Apr 2024 02:17:34 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

This pull request has now been integrated.

Changeset: 0a24daec
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a24daecebd90eb46a813923bb2d5672514197ce
Stats:     16 lines in 3 files changed: 12 ins; 0 del; 4 mod

8322043: HeapDumper should use parallel dump by default

Reviewed-by: yyang, sspitsyn, dholmes

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

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

From duke at openjdk.org  Wed May  1 18:38:03 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 1 May 2024 18:38:03 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <HM17i93lm8bIFW2iM3DSef3c5z3kMZ5i3lg-J6o2eyQ=.35252f4e-2516-4773-bfb1-41feb61d5c68@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
 <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>
 <HM17i93lm8bIFW2iM3DSef3c5z3kMZ5i3lg-J6o2eyQ=.35252f4e-2516-4773-bfb1-41feb61d5c68@github.com>
Message-ID: <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com>

On Wed, 1 May 2024 17:47:47 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> should it not be comparing pid namespace ids and not pids?
>
> Do you mean that it should compare the input PID against the outermost (leftmost) PID in the `NSpid` list from `/proc/<pid>/status` and not innermost (rightmost) as is done right now? What would be the benefit of that? Or did you mean something else?
> 
> I'm working on a fix for https://bugs.openjdk.org/browse/JDK-8327114 right now, and it occurred to me that there is a tiny risk of `pid != ns_pid` not evaluating to `true` even though the processes are in different PID namespaces (because two different PID namespaces can have the same PIDs). I think it could be mitigated by always trying `/proc/<pid>/root/tmp` first, and if it cannot be read, fall back to `/tmp`.

c.f: /proc/<pid>/ns/pid 

every (Linux) namespace has a unique id, if 2 (or more) processes occupy the same pid namespace (or any other for that matter) then their ../ns/pid namespace ids will be the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1586623838

From cjplummer at openjdk.org  Wed May  1 19:24:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 May 2024 19:24:55 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
Message-ID: <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>

On Tue, 30 Apr 2024 12:08:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address additional problem listed tests in hotspot/jtreg/serviceability

test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java line 77:

> 75:             t.setDaemon(false);
> 76:         }
> 77:         testThread(t, "");

I think the following is a bit clearer:


// Virtual threads are always daemon threads. Therefore if the current thread is a
// virtual thread, then NormalThread will be a daemon thread and we need to explicitly
// make it not a daemon thread.


You don't actually need the isVirtual() check, especially with the comment explaining things. However, you could also forgo all this logic and the comment by just sticking setDaemon(false) in the NormalThread constructor.

test/jdk/sun/tools/jstack/BasicJStackTest.java line 53:

> 51:             // print the stacktraces of virtual threads.
> 52:             throw new SkippedException("skipping test since current thread is a virtual thread");
> 53:         }

I wonder if we can rely on the virtual thread always be mounted. If so, we could revisit this test after [JDK-8330846](https://bugs.openjdk.org/browse/JDK-8330846) is implemented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1586668634
PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1586695143

From duke at openjdk.org  Wed May  1 20:10:01 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 1 May 2024 20:10:01 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
 <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>
 <HM17i93lm8bIFW2iM3DSef3c5z3kMZ5i3lg-J6o2eyQ=.35252f4e-2516-4773-bfb1-41feb61d5c68@github.com>
 <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com>
Message-ID: <7Syh73jRLW_T1RX1pKDT0YGFrCrhDz0GA8hh8p0gVdc=.cdff1cef-6885-479f-9290-117992fea52a@github.com>

On Wed, 1 May 2024 18:35:29 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Do you mean that it should compare the input PID against the outermost (leftmost) PID in the `NSpid` list from `/proc/<pid>/status` and not innermost (rightmost) as is done right now? What would be the benefit of that? Or did you mean something else?
>> 
>> I'm working on a fix for https://bugs.openjdk.org/browse/JDK-8327114 right now, and it occurred to me that there is a tiny risk of `pid != ns_pid` not evaluating to `true` even though the processes are in different PID namespaces (because two different PID namespaces can have the same PIDs). I think it could be mitigated by always trying `/proc/<pid>/root/tmp` first, and if it cannot be read, fall back to `/tmp`.
>
> c.f: /proc/<pid>/ns/pid 
> 
> every (Linux) namespace has a unique id, if 2 (or more) processes occupy the same pid namespace (or any other for that matter) then their ../ns/pid namespace ids will be the same.

**`Files.readSymbolicLink(Path.of("/proc/self/ns/pid"))`**

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1586769059

From duke at openjdk.org  Wed May  1 20:33:05 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 1 May 2024 20:33:05 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <7Syh73jRLW_T1RX1pKDT0YGFrCrhDz0GA8hh8p0gVdc=.cdff1cef-6885-479f-9290-117992fea52a@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
 <TCWPFxauce6MdbR-LIF3-hPnHTC3SyXG315jwcA3CuA=.70b77b9e-da15-4154-8ac9-20c0f85bfaa1@github.com>
 <HM17i93lm8bIFW2iM3DSef3c5z3kMZ5i3lg-J6o2eyQ=.35252f4e-2516-4773-bfb1-41feb61d5c68@github.com>
 <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com>
 <7Syh73jRLW_T1RX1pKDT0YGFrCrhDz0GA8hh8p0gVdc=.cdff1cef-6885-479f-9290-117992fea52a@github.com>
Message-ID: <j5x09w5_9WVYrHfhT9pXKTfV4spUW0Kgf7C1wQ7CBEA=.fe5780f2-488e-436e-b574-3e6a8c5acf28@github.com>

On Wed, 1 May 2024 20:07:00 GMT, Larry Cable <duke at openjdk.org> wrote:

>> c.f: /proc/<pid>/ns/pid 
>> 
>> every (Linux) namespace has a unique id, if 2 (or more) processes occupy the same pid namespace (or any other for that matter) then their ../ns/pid namespace ids will be the same.
>
> **`Files.readSymbolicLink(Path.of("/proc/self/ns/pid"))`**

h'mmm ignore my ramblings for now, I need to spend some more time looking into this before wading into the fray with random opinions etc!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1586791713

From jdoyle at iso-ne.com  Wed May  1 21:03:48 2024
From: jdoyle at iso-ne.com (Doyle, James, K)
Date: Wed, 1 May 2024 21:03:48 +0000
Subject: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
 (Kubernetes debug container)
Message-ID: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>

Hi Sebastian,

> I think I can confirm that there is a regression.

Thanks for reproducing the regression, your test makes sense to me, and I think it is similar to the scenario we have with Kubernetes debug containers (separate filesystems, but same PID namespace).

I noticed some of the other recent Pull Request comments on https://github.com/openjdk/jdk/pull/17628:

> should it not be comparing pid namespace ids and not pids?

and wanted to give a little feedback.  I think more refined approaches to figuring out whether the target JVM is in the same PID namespace make sense and could be an improvement, but it's still different from figuring out whether the target JVM has the same filesystem (specifically, I guess, the filesystem containing /tmp or java.io.tmpdir).  That seems like the crucial thing for deciding what socket file path to read, and whether /tmp is sufficient or /proc/<pid>/root/tmp is needed.  I can think of a couple different approaches to the filesystem issue:

1. There is some Linux kernel information that can be obtained about the jcmd process and the target JVM process to figure out unequivocally what their root filesystems are from the host's point of view, and whether they're the same.  (I don't know what this might be, though!)
2. jcmd treats it as a heuristic and attempts each way during the socket file read - first /proc/<pid>/root/tmp and then /tmp.
3. jcmd has some option or environment variable where the user can tell it the socket file path.

Do you agree that these are the types of choices available?

Thanks,
Jim


From cjplummer at openjdk.org  Wed May  1 21:42:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 May 2024 21:42:11 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <zi8pWiMGRfDDfqCgHztwnzjewwQrD8vAauQmr6dF2CI=.eaf6f764-a232-4b41-ac83-de54c0ffa762@github.com>

On Wed, 1 May 2024 21:32:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

I was able to minimize changes for users of RawMonitor by keeping the same client wrapper APIs (eg. debugMonitorEnter), and for the most part passing in the same argument (the monitor to enter). The only change is that the client is passing a new type called DebugRawMonitor* instead of a jrawMonitorID. The DebugRawMonitor encapsulates the jrawMonitorID and contains other monitor info that needs to be tracked (like the rank and current owner).

Ranks were determined largely by trial and error by running tests and fixing the rank violations asserts as I hit them. In the enum that contains all the rankings, I explain the rational for each monitor's rank.

For the moment I have included a flag (rankedmonitors) to control whether or not ranked monitors should be used. This is just a safety net in case someone runs into an issue. The flag is not documented and will likely be removed at some point.

The ranked monitor supported ended up needing a RawMonitor itself (dbgRawMonitor_lock). This RawMonitor is therefore not part of the ranked monitor support. It could probably use a better name. Suggestions are welcomed.

There are a few issues I fixed while working on the ranked monitor support:

During debug agent initialization we need to call util_initialize() before commonRef_initialize() because the later creates a monitor, and that depends on util_initialize() having already been called.

getLocks() in threadControl.c wasn't grabbing locks in the right order. This could have lead to a deadlock, but seems the structure of how locks are used prevented one from happening.

In invoker_completeInvokeRequest() I had to add grabbing the stepLock in order to maintain proper lock order when getLocks() was eventually called (which also grabbed stepLock). Other than triggering a rank violation assert, this doesn't seem to have caused any real issue, but did leave the potential for a deadlock.

In handleInterrupt() I noticed that a local JNI ref was not being freed. I noticed because there were other places where I had added calls to threadControl_currentThread() that resulted in a noticeable JNI ref leak. When I fixed those, I fixed the one in handleInterrupt() too even tough it was not causing any problems.

The ranked monitor APIs needed some extra safeguards during VM exit that are not needed for the unranked monitor APIs. This is because the unranked APIs didn't have a problem with the current thread being NULL, but the ranked APIs require a valid current thread. That is why you see the following check:


    if (gdata->vmDead && current_thread == NULL) {
        return;
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2089176402

From cjplummer at openjdk.org  Wed May  1 21:42:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 May 2024 21:42:11 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
Message-ID: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>

This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work

There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.

Tested with the following on all supported platforms and with virtual threads:

com/sun/jdi
vmTestbase/nsk/jdi
vmTestbase/nsk/jdb
vmTestbase/nsk/jdwp 

Still need to run tier2 and tier5.

Details of the changes follow in the first comment.

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

Commit messages:
 - Fix jchecks errors
 - Add ranked monitor support to the debug agent.

Changes: https://git.openjdk.org/jdk/pull/19044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328866
  Stats: 591 lines in 11 files changed: 515 ins; 5 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/19044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044

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

From larry.cable at oracle.com  Wed May  1 22:19:19 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 1 May 2024 15:19:19 -0700
Subject: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
Message-ID: <787aae2a-36a8-41fe-a797-a5a4a0e1b701@oracle.com>



On 5/1/24 2:03 PM, Doyle, James, K wrote:
> Hi Sebastian,
>
>> I think I can confirm that there is a regression.
> Thanks for reproducing the regression, your test makes sense to me, and I think it is similar to the scenario we have with Kubernetes debug containers (separate filesystems, but same PID namespace).
>
> I noticed some of the other recent Pull Request comments on https://github.com/openjdk/jdk/pull/17628:
>
>> should it not be comparing pid namespace ids and not pids?
> and wanted to give a little feedback.  I think more refined approaches to figuring out whether the target JVM is in the same PID namespace make sense and could be an improvement, but it's still different from figuring out whether the target JVM has the same filesystem (specifically, I guess, the filesystem containing /tmp or java.io.tmpdir).  That seems like the crucial thing for deciding what socket file path to read, and whether /tmp is sufficient or /proc/<pid>/root/tmp is needed.  I can think of a couple different approaches to the filesystem issue:
>
> 1. There is some Linux kernel information that can be obtained about the jcmd process and the target JVM process to figure out unequivocally what their root filesystems are from the host's point of view, and whether they're the same.  (I don't know what this might be, though!)

one could compare the /proc/<pid>/ns/mnt if they are the same the 
processes share the same mount namespace - which by

the 'target' JVM should (always) create the attach socket in its 
/proc/self/root/tmp directory...
> 2. jcmd treats it as a heuristic and attempts each way during the socket file read - first /proc/<pid>/root/tmp and then /tmp.

this was my thought also if the "attacher" JVM and the "attachee" are 
not in the same (mount or pid) namespace then it seems highly unlikely 
that they can communicate via a filesystem namespace mechanism.

> 3. jcmd has some option or environment variable where the user can tell it the socket file path.

we could do this but this would require a filesystem in common as with 
the existing "attach a shared volume" solution
>
> Do you agree that these are the types of choices available?
>
> Thanks,
> Jim
>


From cjplummer at openjdk.org  Wed May  1 21:27:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 May 2024 21:27:01 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>

On Wed, 1 May 2024 10:20:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

I've only looked at specs and tests so far. Still need to review the JVMTI code changes. I looked at the CSR too, but thought it best to just comment on the spec changes here.

src/hotspot/share/prims/jvmti.xml line 8259:

> 8257:           <jint/>
> 8258:           <description>
> 8259:             The number of times the owning platform thread has entered the monitor

"the owning platform thread" doesn't really make sense if the monitor is owned by a virtual thread. You might want structure it more like the "owner" description above:


The number of times the platform thread owning this monitor has has entered it, 
or <code>0</code> if owned by a virtual thread or not owned

src/hotspot/share/prims/jvmti.xml line 8266:

> 8264:           <description>
> 8265:             The number of platform threads waiting to own this monitor,
> 8266:             or <code>0</code> if the monitor is owned by a virtual thread or not owned

Be consistent with above descriptions. They don't say "if the monitor is owned by". They say "if owned by".

src/hotspot/share/prims/jvmti.xml line 8279:

> 8277:           <description>
> 8278:             The number of platform threads waiting to be notified by this monitor,
> 8279:             or <code>0</code> if the monitor is owned by a virtual thread or not owned

Same consistency issue as with `waiter_count`

src/java.se/share/data/jdwp/jdwp.spec line 1620:

> 1618:         )
> 1619:         (Reply
> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "

I don't think we should be introducing `<code>nullptr</code>` for just this one location. Please stick with `null` for now.

src/java.se/share/data/jdwp/jdwp.spec line 1621:

> 1619:         (Reply
> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
> 1621:                                 "if owned` by a virtual thread or not owned.")

You have a dangling back quote after "owned". This is showing up in the CSR too.

src/java.se/share/data/jdwp/jdwp.spec line 1622:

> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
> 1621:                                 "if owned` by a virtual thread or not owned.")
> 1622:             (int entryCount "The number of times the owning platform thread has entered the monitor.")

See the comment I left for the JVMTI spec. We should be more complete in the explanation here, explaining how it is 0 for virtual threads.

src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 348:

> 346:     /**
> 347:      * Returns a List containing a {@link ThreadReference} for
> 348:      * each platform thread currently waiting for this object's monitor.

You need to add "platform" a little below in the `@return` section.

src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 369:

> 367: 
> 368:     /**
> 369:      * Returns an {@link ThreadReference} for the platform thread, if any,

Pre-existing issue: It should be "a" not "an", but then in the `@return` section we are using "the", so maybe we should use similar wording here: `...the {@link ThreadReference} of the platform thread...`

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 257:

> 255:             // Correct the expected values for the virtual thread case.
> 256:             int expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS;
> 257:             int expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS;

There are comments below that still reference NUMBER_OF_ENTERING_THREADS  and NUMBER_OF_WAITING_THREADS.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads002.java line 167:

> 165:                     try {
> 166:                         List waitingThreads = objRef.waitingThreads();
> 167:                         if (waitingThreads.size() != expWaitingCount) {

I don't see the need for the expWaitingCount bookkeeping. Can't we just verify that size() is zero if we are using virtual threads? I guess maybe the reason you took this approach is because you don't know if the threads are going to be virtual or not until you check them. There is a way to find out, but it's not that pretty either:

    static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 65:

> 63:         }
> 64:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
> 65:         // the expected values if the test is executed with MainWrapper=virtual.

"MainWrapper" is not the proper terminology any more.  It's "Test Thread Factory" (JTREG_TEST_THREAD_FACTORY=Virtual).

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 158:

> 156:     public void run() {
> 157:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
> 158:         // the expected values if the test is executed with MainWrapper=virtual.

"MainWrapper" again.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004.java line 64:

> 62:         synchronized (lockCheck) {
> 63:             // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
> 64:             // the expected values if the test is executed with MainWrapper=virtual.

"MainWrappe" again.

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

PR Review: https://git.openjdk.org/jdk/pull/19030#pullrequestreview-2034390826
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586784250
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586784280
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586792380
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586800777
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586802318
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586803324
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586806802
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586809854
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586833617
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586821719
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586824426
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586827714
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586829010

From sspitsyn at openjdk.org  Wed May  1 22:34:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 22:34:52 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <U6ajcKLKCOL_j-j55PxL3cG3cjFofhjbFjyoE1Rrnsk=.a0ca021e-8c5b-4be8-a554-6674041266fa@github.com>

On Wed, 1 May 2024 20:21:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmti.xml line 8259:
> 
>> 8257:           <jint/>
>> 8258:           <description>
>> 8259:             The number of times the owning platform thread has entered the monitor
> 
> "the owning platform thread" doesn't really make sense if the monitor is owned by a virtual thread. You might want structure it more like the "owner" description above:
> 
> 
> The number of times the platform thread owning this monitor has has entered it, 
> or <code>0</code> if owned by a virtual thread or not owned

Good suggestion, thanks. It is more consistent this way. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586890106

From sspitsyn at openjdk.org  Wed May  1 22:42:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 22:42:52 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>

On Wed, 1 May 2024 20:21:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmti.xml line 8266:
> 
>> 8264:           <description>
>> 8265:             The number of platform threads waiting to own this monitor,
>> 8266:             or <code>0</code> if the monitor is owned by a virtual thread or not owned
> 
> Be consistent with above descriptions. They don't say "if the monitor is owned by". They say "if owned by".

Good suggestion, thanks. But it is more "incorrect". It should say "is waited by" instead of "is owned by":

           The number of platform threads waiting to own this monitor, or <code>0</code>
           if the monitor is waited by virtual threads only or not owned
``` 
Are you okay with this correction?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586894427

From sspitsyn at openjdk.org  Wed May  1 22:58:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 22:58:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <AXbuNfgBanGBAq7LPueiEYcp-XfiItxv_4VACCwdN8s=.a8fdfc70-cfc9-453b-9818-3a80c2c64d25@github.com>

On Wed, 1 May 2024 20:30:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmti.xml line 8279:
> 
>> 8277:           <description>
>> 8278:             The number of platform threads waiting to be notified by this monitor,
>> 8279:             or <code>0</code> if the monitor is owned by a virtual thread or not owned
> 
> Same consistency issue as with `waiter_count`

Thanks. Let's align it with `waiter_count` solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586902737

From sspitsyn at openjdk.org  Wed May  1 23:02:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 23:02:52 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <hWs7Xf-ntkLKDW1C6IwI7D-yZvrPvDTDut3feM9xIeI=.3951dcb2-881a-4810-988f-baad3298d4b1@github.com>

On Wed, 1 May 2024 20:40:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> src/java.se/share/data/jdwp/jdwp.spec line 1620:
> 
>> 1618:         )
>> 1619:         (Reply
>> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
> 
> I don't think we should be introducing `<code>nullptr</code>` for just this one location. Please stick with `null` for now.

Good catch, thanks. Updated.

> src/java.se/share/data/jdwp/jdwp.spec line 1621:
> 
>> 1619:         (Reply
>> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
>> 1621:                                 "if owned` by a virtual thread or not owned.")
> 
> You have a dangling back quote after "owned". This is showing up in the CSR too.

Thanks. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586905504
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586905989

From sspitsyn at openjdk.org  Wed May  1 23:09:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 May 2024 23:09:55 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <gLGrh4UfG44sXNqsSwVugL142T71Rr5se96cfWkIexM=.45759aa3-0dcd-4743-8cc3-a1aacc9c719b@github.com>

On Wed, 1 May 2024 21:03:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 65:
> 
>> 63:         }
>> 64:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 65:         // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrapper" is not the proper terminology any more.  It's "Test Thread Factory" (JTREG_TEST_THREAD_FACTORY=Virtual).

Good suggestion, thanks. Then I'd suggest this:

        // Virtual threads are not supported by the GetObjectMonitorUsage.
        // Correct the expected values if the test is executed with the
        // JTREG_TEST_THREAD_FACTORY=Virtual.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 158:
> 
>> 156:     public void run() {
>> 157:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 158:         // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrapper" again.

Thanks. Same as above.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004.java line 64:
> 
>> 62:         synchronized (lockCheck) {
>> 63:             // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 64:             // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrappe" again.

Thanks. Same as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586908764
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586908965
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586909037

From cjplummer at openjdk.org  Wed May  1 23:20:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 May 2024 23:20:52 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
Message-ID: <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>

On Wed, 1 May 2024 22:40:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 8266:
>> 
>>> 8264:           <description>
>>> 8265:             The number of platform threads waiting to own this monitor,
>>> 8266:             or <code>0</code> if the monitor is owned by a virtual thread or not owned
>> 
>> Be consistent with above descriptions. They don't say "if the monitor is owned by". They say "if owned by".
>
> Good suggestion, thanks. But it is more "incorrect". It should say "is waited by" instead of "is owned by":
> 
>            The number of platform threads waiting to own this monitor, or <code>0</code>
>            if is waited by virtual threads only or no threads are waiting
> ``` 
> Are you okay with this correction?
> Or maybe we should say:
> 
>            The number of platform threads waiting to own this monitor, or <code>0</code>
>            if virtual threads only are waiting or no threads are waiting

Copy and paste issue on my part. I would use "if only virtual threads".

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 65:
>> 
>>> 63:         }
>>> 64:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>>> 65:         // the expected values if the test is executed with MainWrapper=virtual.
>> 
>> "MainWrapper" is not the proper terminology any more.  It's "Test Thread Factory" (JTREG_TEST_THREAD_FACTORY=Virtual).
>
> Good suggestion, thanks. Then I'd suggest this:
> 
>         // Virtual threads are not supported by the GetObjectMonitorUsage.
>         // Correct the expected values if the test is executed with the
>         // JTREG_TEST_THREAD_FACTORY=Virtual.

You can drop "the" from "with the JTREG_TEST_THREAD_FACTORY=Virtual"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586913098
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586913936

From larry.cable at oracle.com  Thu May  2 00:43:53 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 1 May 2024 17:43:53 -0700
Subject: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
Message-ID: <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>

just to demonstrate:

$ docker run -it --name=js1? openjdk:17.0.1-jdk? /bin/jshell
...
$ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 /bin/jshell


$ docker exec -it js1? bash
bash-4.4# ls /tmp/hsperfdata_root
1? 26
bash-4.4# readlink /proc/26/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/26/ns/mnt
mnt:[4026532747]
bash-4.4# exit
[lpgc at arran ~]$ docker exec -it js2? bash
bash-4.4# ls /tmp/hsperfdata_root
107? 82
bash-4.4# readlink /proc/107/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/107/ns/mnt
mnt:[4026532941]

you will note that the JVM pid: 26 and 107 occupy the same pid namespace 
(4026532751) but occupy different mnt namespaces (4026532747, 4026532941)

therefore attempting to attach via '/tmp' will fail, 
/proc/<pid>/root/tmp must be used to rendezvous

- Larry


On 5/1/24 2:03 PM, Doyle, James, K wrote:
> Hi Sebastian,
>
>> I think I can confirm that there is a regression.
> Thanks for reproducing the regression, your test makes sense to me, and I think it is similar to the scenario we have with Kubernetes debug containers (separate filesystems, but same PID namespace).
>
> I noticed some of the other recent Pull Request comments on https://github.com/openjdk/jdk/pull/17628:
>
>> should it not be comparing pid namespace ids and not pids?
> and wanted to give a little feedback.  I think more refined approaches to figuring out whether the target JVM is in the same PID namespace make sense and could be an improvement, but it's still different from figuring out whether the target JVM has the same filesystem (specifically, I guess, the filesystem containing /tmp or java.io.tmpdir).  That seems like the crucial thing for deciding what socket file path to read, and whether /tmp is sufficient or /proc/<pid>/root/tmp is needed.  I can think of a couple different approaches to the filesystem issue:
>
> 1. There is some Linux kernel information that can be obtained about the jcmd process and the target JVM process to figure out unequivocally what their root filesystems are from the host's point of view, and whether they're the same.  (I don't know what this might be, though!)
> 2. jcmd treats it as a heuristic and attempts each way during the socket file read - first /proc/<pid>/root/tmp and then /tmp.
> 3. jcmd has some option or environment variable where the user can tell it the socket file path.
>
> Do you agree that these are the types of choices available?
>
> Thanks,
> Jim
>


From sspitsyn at openjdk.org  Thu May  2 00:53:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 00:53:58 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
 <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
Message-ID: <O47jgI28nEeVrS_56m8qS2VqJbnvhkDOqcTMr76pkWk=.5cb76804-c8a0-4af3-9286-25569e4c0066@github.com>

On Wed, 1 May 2024 23:16:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Good suggestion, thanks. But it is more "incorrect". It should say "is waited by" instead of "is owned by":
>> 
>>            The number of platform threads waiting to own this monitor, or <code>0</code>
>>            if is waited by virtual threads only or no threads are waiting
>> ``` 
>> Are you okay with this correction?
>> Or maybe we should say:
>> 
>>            The number of platform threads waiting to own this monitor, or <code>0</code>
>>            if virtual threads only are waiting or no threads are waiting
>
> Copy and paste issue on my part. I would use "if only virtual threads".

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586955071

From dholmes at openjdk.org  Thu May  2 02:52:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 May 2024 02:52:00 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <O47jgI28nEeVrS_56m8qS2VqJbnvhkDOqcTMr76pkWk=.5cb76804-c8a0-4af3-9286-25569e4c0066@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
 <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
 <O47jgI28nEeVrS_56m8qS2VqJbnvhkDOqcTMr76pkWk=.5cb76804-c8a0-4af3-9286-25569e4c0066@github.com>
Message-ID: <Z4HrekMe6a5PYADHY0136SQrwbZ_wqTWBEtErAJhBeQ=.c0dd4154-4731-4f61-9628-88fa678dba79@github.com>

On Thu, 2 May 2024 00:51:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Copy and paste issue on my part. I would use "if only virtual threads".
>
> Okay, thanks.

Second suggestion is better. "waited by" is not grammatically correct in this context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587002775

From dholmes at openjdk.org  Thu May  2 02:52:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 May 2024 02:52:01 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
 <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
Message-ID: <NJTw28NbNRBalwM-hZeOs-gL9ohWM-72McgKE0PZu1A=.e1152e70-e8d9-4a86-ac7e-946a7af2878c@github.com>

On Wed, 1 May 2024 23:17:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Good suggestion, thanks. Then I'd suggest this:
>> 
>>         // Virtual threads are not supported by the GetObjectMonitorUsage.
>>         // Correct the expected values if the test is executed with the
>>         // JTREG_TEST_THREAD_FACTORY=Virtual.
>
> You can drop "the" from "with the JTREG_TEST_THREAD_FACTORY=Virtual"

And drop "the" from "the GetObjectMonitorUsage".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587003633

From jpai at openjdk.org  Thu May  2 03:57:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 03:57:25 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v3]
In-Reply-To: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
Message-ID: <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>

> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
> 
> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
> 
> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
> 
> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
> 
> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Chris' review - DaemonThreadTest.java, no need for checking if thread is virtual

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19016/files
  - new: https://git.openjdk.org/jdk/pull/19016/files/6193cfbb..d9e92144

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

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

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

From jpai at openjdk.org  Thu May  2 03:59:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 03:59:52 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
 <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>
Message-ID: <8Xpm3fH_1mWw283vz0-cQAzLc5D3gUHedRsSC0Eb6zY=.8e2672a3-d81b-4d3d-8fe1-a04fb221a3aa@github.com>

On Wed, 1 May 2024 19:02:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address additional problem listed tests in hotspot/jtreg/serviceability
>
> test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java line 77:
> 
>> 75:             t.setDaemon(false);
>> 76:         }
>> 77:         testThread(t, "");
> 
> I think the following is a bit clearer:
> 
> 
> // Virtual threads are always daemon threads. Therefore if the current thread is a
> // virtual thread, then NormalThread will be a daemon thread and we need to explicitly
> // make it not a daemon thread.
> 
> 
> You don't actually need the isVirtual() check, especially with the comment explaining things. However, you could also forgo all this logic and the comment by just sticking setDaemon(false) in the NormalThread constructor.

Done - I've updated the PR to just call `setDaemon(false)`  from the constructor of `NormalThread` instead of this conditional logic.

When I initially added this logic, I was trying to avoid doing any changes that could impact the testing when running under platform threads. But thinking about this test's context, it merely wants to verify that the jstack output correctly presents daemon/non-daemon status, so explicitly setting a "normal" thread to non-daemon shouldn't impact what this test was originally verifying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1587033311

From jpai at openjdk.org  Thu May  2 04:09:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 04:09:59 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
 <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>
Message-ID: <n5gqFLxdt-gaD9KTzPumbW8zKPCvUm6DtCqUVOeSn-w=.6e68dba5-e8b0-4665-bb62-5e8a312c9311@github.com>

On Wed, 1 May 2024 19:15:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address additional problem listed tests in hotspot/jtreg/serviceability
>
> test/jdk/sun/tools/jstack/BasicJStackTest.java line 53:
> 
>> 51:             // print the stacktraces of virtual threads.
>> 52:             throw new SkippedException("skipping test since current thread is a virtual thread");
>> 53:         }
> 
> I wonder if we can rely on the virtual thread always be mounted. If so, we could revisit this test after [JDK-8330846](https://bugs.openjdk.org/browse/JDK-8330846) is implemented.

Hello Chris, if I understand that JBS issue correctly, then by default jstack (and other tools) will start including stacktraces of virtual threads that currently are mounted on a carrier thread (and thus haven't been parked) in the output.

If that's the case, then I think when that JBS issue is implemented we can remove this conditional check and the skipping of the test since the virtual thread would end up appearing in the thread dump because that's the thread which would be currently launching the `jstack` process and waiting (through a `ReentrantLock`'s `Condition` object) for the jstack process to complete.

To revisit this test when JDK-8330846 is implemented, do you want me to file an issue? Or did you mean we should wait doing the changes in this PR until JDK-8330846 is implemented?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1587037457

From sspitsyn at openjdk.org  Thu May  2 06:37:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 06:37:54 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <Z4HrekMe6a5PYADHY0136SQrwbZ_wqTWBEtErAJhBeQ=.c0dd4154-4731-4f61-9628-88fa678dba79@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
 <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
 <O47jgI28nEeVrS_56m8qS2VqJbnvhkDOqcTMr76pkWk=.5cb76804-c8a0-4af3-9286-25569e4c0066@github.com>
 <Z4HrekMe6a5PYADHY0136SQrwbZ_wqTWBEtErAJhBeQ=.c0dd4154-4731-4f61-9628-88fa678dba79@github.com>
Message-ID: <3PBlt6Id-KHcyBKctS2jcAxbKFQuAQRlG1kIWHwnDWk=.956935c8-0a78-4778-8875-f378414aa94e@github.com>

On Thu, 2 May 2024 02:47:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay, thanks.
>
> Second suggestion is better. "waited by" is not grammatically correct in this context.

Thank you, David.
So, the latest version is:

           The number of platform threads waiting to own this monitor, or <code>0</code>
           if only virtual threads are waiting or no threads are waiting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587131816

From sspitsyn at openjdk.org  Thu May  2 06:43:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 06:43:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <NJTw28NbNRBalwM-hZeOs-gL9ohWM-72McgKE0PZu1A=.e1152e70-e8d9-4a86-ac7e-946a7af2878c@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <u9Th6XKo2vTZYfQHct1COpe5U-STYZ0iWW1f7MoVufE=.f4aaca15-cb79-4420-a377-6c8e534d657a@github.com>
 <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com>
 <NJTw28NbNRBalwM-hZeOs-gL9ohWM-72McgKE0PZu1A=.e1152e70-e8d9-4a86-ac7e-946a7af2878c@github.com>
Message-ID: <JCZVIe2Kv1__kE8ZuwRhLIKl4_q4LRntUilKAafPWZs=.f4091097-b7ea-4e56-b82a-629504d9688f@github.com>

On Thu, 2 May 2024 02:49:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> You can drop "the" from "with the JTREG_TEST_THREAD_FACTORY=Virtual"
>
> And drop "the" from "the GetObjectMonitorUsage".

Thank you. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587137513

From sspitsyn at openjdk.org  Thu May  2 06:48:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 06:48:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>

On Wed, 1 May 2024 21:11:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 257:
> 
>> 255:             // Correct the expected values for the virtual thread case.
>> 256:             int expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS;
>> 257:             int expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS;
> 
> There are comments below that still reference NUMBER_OF_ENTERING_THREADS  and NUMBER_OF_WAITING_THREADS.

Thank you for the comment. In fact, I don't know how to fix it.
Replacing with `expEnteringCount/expWaitingCount` does not make sense to me.
The comments are about the tested pattern, not about the real values.
Please, let me know if you have any suggestion on fixing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587142283

From sspitsyn at openjdk.org  Thu May  2 07:23:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 07:23:55 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <ho9vtKcVfQqW3IKpQ7yoQftrF4N7gbdY8jYUY6ZvnMs=.e7b61e05-d1da-464f-b173-74c414fde143@github.com>

On Wed, 1 May 2024 21:01:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads002.java line 167:
> 
>> 165:                     try {
>> 166:                         List waitingThreads = objRef.waitingThreads();
>> 167:                         if (waitingThreads.size() != expWaitingCount) {
> 
> I don't see the need for the expWaitingCount bookkeeping. Can't we just verify that size() is zero if we are using virtual threads? I guess maybe the reason you took this approach is because you don't know if the threads are going to be virtual or not until you check them. There is a way to find out, but it's not that pretty either:
> 
>     static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));

Thank you for the suggestion. Updated with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587177852

From sspitsyn at openjdk.org  Thu May  2 07:33:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 07:33:09 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/9a3b8192..7465f064

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

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

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

From shade at openjdk.org  Thu May  2 09:08:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 2 May 2024 09:08:57 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v6]
In-Reply-To: <oKw_lwvggGR1lO90lIqvwzDVsV0Qqp0heQgm-TGdFjU=.a27a162d-b28f-4b22-9a3d-3d185666ddac@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <oKw_lwvggGR1lO90lIqvwzDVsV0Qqp0heQgm-TGdFjU=.a27a162d-b28f-4b22-9a3d-3d185666ddac@github.com>
Message-ID: <s9M4Ty1IyPQiqVUkp-gvCMq7R3pWyMYPlrstY1z25ws=.a826bf42-7ac5-4163-bde9-74a415994f2f@github.com>

On Tue, 30 Apr 2024 18:54:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed space-only change in diagnosticCommand.cpp

Late to the party here, sorry. 

Are there motivational performance improvements that we get from enabling parallel heap dumps by default? Asking because [JDK-8319650](https://bugs.openjdk.org/browse/JDK-8319650) and [JDK-8320924](https://bugs.openjdk.org/browse/JDK-8320924) improved single-threaded heap dump performance drastically, and the I/O looked to be a bottleneck going forward. 

Would parallel heap dump take _more_ I/O for writing chunks first, and then combining them into large file? Do we know that parallel heap dump still wins a lot? I don't think it does all that much. Here is a simple run using the workload from [JDK-8319650](https://bugs.openjdk.org/browse/JDK-8319650) on 10-core machine:


$ for I in `seq 1 5`; do java -XX:+UseParallelGC -XX:+HeapDumpAfterFullGC -Xms8g -Xmx8g HeapDump.java 2>&1 | grep created; rm *.hprof; done

# jdk mainline with this fix (parallel)
Heap dump file created [1897668110 bytes in 1.401 secs]
Heap dump file created [1897667841 bytes in 1.354 secs]
Heap dump file created [1897668050 bytes in 1.440 secs]
Heap dump file created [1897668101 bytes in 1.366 secs]
Heap dump file created [1897668101 bytes in 1.345 secs]

# jdk mainline without this fix (sequential)
Heap dump file created [1897668092 bytes in 2.314 secs]
Heap dump file created [1897668092 bytes in 2.384 secs]
Heap dump file created [1897668092 bytes in 2.269 secs]
Heap dump file created [1897668092 bytes in 2.274 secs]
Heap dump file created [1897667816 bytes in 2.282 secs]


This is less than 2x improvement, even though we took 3 threads to heap dump:


[1.645s][info][heapdump] Requested dump threads 3, active dump threads 9, actual dump threads 3, parallelism true
[1.649s][info][heapdump] Dump non-objects, 0.0046221 secs
[1.651s][info][heapdump] Dump non-objects (part 2), 0.0019995 secs
[2.230s][info][heapdump] Dump heap objects in parallel, 0.5850964 secs
[2.230s][info][heapdump] Dump heap objects in parallel, 0.5852571 secs
[2.230s][info][heapdump] Dump heap objects in parallel, 0.5790543 secs
[2.558s][info][heapdump] Merge segmented heap file, 0.3268282 secs
[2.863s][info][heapdump] Merge segmented heap file, 0.3047630 secs
[3.307s][info][heapdump] Merge segmented heap file, 0.4436261 secs
[3.308s][info][heapdump] Merge heap files complete, 1.0766620 secs
Heap dump file created [1897667959 bytes in 1.664 secs]


And this is on a fast SSD, where I/O is abundant, and there is plenty of space.
The sequential heap dump also seems to be regressing against jdk21u-dev, which does:


Heap dump file created [1897840374 bytes in 1.071 secs]
Heap dump file created [1897840481 bytes in 1.070 secs]
Heap dump file created [1897840490 bytes in 1.069 secs]
Heap dump file created [1897840481 bytes in 1.073 secs]
Heap dump file created [1897840481 bytes in 1.134 secs]


I believe that is because the 2-phase heap dump makes excess work for a single-threaded heap dump. Note that the _parallel_ heap dump in current mainline is not even able to catch up with *what we already had* with _sequential_ heap dump.

I propose we revert this switch to parallel, fix the sequential heap dump performance, and then reconsider -- with benchmarks -- if we want to switch to parallel.

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

PR Comment: https://git.openjdk.org/jdk/pull/18748#issuecomment-2089957067

From sebastian.lovdahl at hibox.tv  Thu May  2 10:09:24 2024
From: sebastian.lovdahl at hibox.tv (=?UTF-8?Q?Sebastian_L=C3=B6vdahl?=)
Date: Thu, 2 May 2024 13:09:24 +0300
Subject: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>
References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
 <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>
Message-ID: <cbb59f1e-c843-44b1-accb-813c5a96e961@hibox.tv>

Interesting, TIL about /proc/<pid>/ns. I tried to look for something 
like that but couldn't find anything relevant in /proc/<pid>/status.

So, a pixel perfect solution could compare these IDs to know whether 
/tmp or /proc/<pid>/root/tmp should be used.

 > 2. jcmd treats it as a heuristic and attempts each way during the 
socket file read - first /proc/<pid>/root/tmp and then /tmp.

This is what I had in mind as well, and what I actually implemented and 
tested already. I think I'll just go ahead and open a PR with those 
changes, and we can take it from there.

/Sebastian

On 2024-05-02 03:43, Laurence Cable wrote:
> just to demonstrate:
>
> $ docker run -it --name=js1? openjdk:17.0.1-jdk? /bin/jshell
> ...
> $ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 
> /bin/jshell
>
>
> $ docker exec -it js1? bash
> bash-4.4# ls /tmp/hsperfdata_root
> 1? 26
> bash-4.4# readlink /proc/26/ns/pid
> pid:[4026532751]
> bash-4.4# readlink /proc/26/ns/mnt
> mnt:[4026532747]
> bash-4.4# exit
> [lpgc at arran ~]$ docker exec -it js2? bash
> bash-4.4# ls /tmp/hsperfdata_root
> 107? 82
> bash-4.4# readlink /proc/107/ns/pid
> pid:[4026532751]
> bash-4.4# readlink /proc/107/ns/mnt
> mnt:[4026532941]
>
> you will note that the JVM pid: 26 and 107 occupy the same pid 
> namespace (4026532751) but occupy different mnt namespaces 
> (4026532747, 4026532941)
>
> therefore attempting to attach via '/tmp' will fail, 
> /proc/<pid>/root/tmp must be used to rendezvous
>
> - Larry
>
>
> On 5/1/24 2:03 PM, Doyle, James, K wrote:
>> Hi Sebastian,
>>
>>> I think I can confirm that there is a regression.
>> Thanks for reproducing the regression, your test makes sense to me, 
>> and I think it is similar to the scenario we have with Kubernetes 
>> debug containers (separate filesystems, but same PID namespace).
>>
>> I noticed some of the other recent Pull Request comments on 
>> https://github.com/openjdk/jdk/pull/17628:
>>
>>> should it not be comparing pid namespace ids and not pids?
>> and wanted to give a little feedback.? I think more refined 
>> approaches to figuring out whether the target JVM is in the same PID 
>> namespace make sense and could be an improvement, but it's still 
>> different from figuring out whether the target JVM has the same 
>> filesystem (specifically, I guess, the filesystem containing /tmp or 
>> java.io.tmpdir).? That seems like the crucial thing for deciding what 
>> socket file path to read, and whether /tmp is sufficient or 
>> /proc/<pid>/root/tmp is needed.? I can think of a couple different 
>> approaches to the filesystem issue:
>>
>> 1. There is some Linux kernel information that can be obtained about 
>> the jcmd process and the target JVM process to figure out 
>> unequivocally what their root filesystems are from the host's point 
>> of view, and whether they're the same.? (I don't know what this might 
>> be, though!)
>> 2. jcmd treats it as a heuristic and attempts each way during the 
>> socket file read - first /proc/<pid>/root/tmp and then /tmp.
>> 3. jcmd has some option or environment variable where the user can 
>> tell it the socket file path.
>>
>> Do you agree that these are the types of choices available?
>>
>> Thanks,
>> Jim
>>
>

-- 
Sebastian L?vdahl
Software Architect, Hibox Systems - https://www.hibox.tv
sebastian.lovdahl at hibox.tv


From sspitsyn at openjdk.org  Thu May  2 10:13:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 10:13:00 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
Message-ID: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>

Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.

Testing:
 - TBD: submit mach5 tiers 1-6

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

Commit messages:
 - 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed

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

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

From duke at openjdk.org  Thu May  2 10:19:13 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 2 May 2024 10:19:13 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
Message-ID: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>

8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

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

Commit messages:
 - 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

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

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

From larry.cable at oracle.com  Thu May  2 10:20:01 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 2 May 2024 03:20:01 -0700
Subject: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <cbb59f1e-c843-44b1-accb-813c5a96e961@hibox.tv>
References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
 <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>
 <cbb59f1e-c843-44b1-accb-813c5a96e961@hibox.tv>
Message-ID: <8559e222-b29e-4984-956b-236f2e0e79c2@oracle.com>



On 5/2/24 3:09 AM, Sebastian L?vdahl wrote:
> Interesting, TIL about /proc/<pid>/ns. I tried to look for something 
> like that but couldn't find anything relevant in /proc/<pid>/status.

ok

>
> So, a pixel perfect solution could compare these IDs to know whether 
> /tmp or /proc/<pid>/root/tmp should be used.
>
> > 2. jcmd treats it as a heuristic and attempts each way during the 
> socket file read - first /proc/<pid>/root/tmp and then /tmp.
>
> This is what I had in mind as well, and what I actually implemented 
> and tested already. I think I'll just go ahead and open a PR with 
> those changes, and we can take it from there.

yes, IMO the attachee should always use /proc/self/root/tmp and the 
attacher should compare /proc/<attachee_pid>/ns/mnt with its 
/proc/self/ns/mnt with Path::toString comparison,
if they match then it is "safe" to use /tmp, if they do not then it must 
resort to using /proc/<attachee_pid>/ns/mnt if the attacher does not 
have sufficient privilege to access that due
to attachee capabilities etc then the attach will fail

Rgds

- Larry
>
> /Sebastian
>
> On 2024-05-02 03:43, Laurence Cable wrote:
>> just to demonstrate:
>>
>> $ docker run -it --name=js1? openjdk:17.0.1-jdk? /bin/jshell
>> ...
>> $ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 
>> /bin/jshell
>>
>>
>> $ docker exec -it js1? bash
>> bash-4.4# ls /tmp/hsperfdata_root
>> 1? 26
>> bash-4.4# readlink /proc/26/ns/pid
>> pid:[4026532751]
>> bash-4.4# readlink /proc/26/ns/mnt
>> mnt:[4026532747]
>> bash-4.4# exit
>> [lpgc at arran ~]$ docker exec -it js2? bash
>> bash-4.4# ls /tmp/hsperfdata_root
>> 107? 82
>> bash-4.4# readlink /proc/107/ns/pid
>> pid:[4026532751]
>> bash-4.4# readlink /proc/107/ns/mnt
>> mnt:[4026532941]
>>
>> you will note that the JVM pid: 26 and 107 occupy the same pid 
>> namespace (4026532751) but occupy different mnt namespaces 
>> (4026532747, 4026532941)
>>
>> therefore attempting to attach via '/tmp' will fail, 
>> /proc/<pid>/root/tmp must be used to rendezvous
>>
>> - Larry
>>
>>
>> On 5/1/24 2:03 PM, Doyle, James, K wrote:
>>> Hi Sebastian,
>>>
>>>> I think I can confirm that there is a regression.
>>> Thanks for reproducing the regression, your test makes sense to me, 
>>> and I think it is similar to the scenario we have with Kubernetes 
>>> debug containers (separate filesystems, but same PID namespace).
>>>
>>> I noticed some of the other recent Pull Request comments on 
>>> https://github.com/openjdk/jdk/pull/17628:
>>>
>>>> should it not be comparing pid namespace ids and not pids?
>>> and wanted to give a little feedback.? I think more refined 
>>> approaches to figuring out whether the target JVM is in the same PID 
>>> namespace make sense and could be an improvement, but it's still 
>>> different from figuring out whether the target JVM has the same 
>>> filesystem (specifically, I guess, the filesystem containing /tmp or 
>>> java.io.tmpdir).? That seems like the crucial thing for deciding 
>>> what socket file path to read, and whether /tmp is sufficient or 
>>> /proc/<pid>/root/tmp is needed.? I can think of a couple different 
>>> approaches to the filesystem issue:
>>>
>>> 1. There is some Linux kernel information that can be obtained about 
>>> the jcmd process and the target JVM process to figure out 
>>> unequivocally what their root filesystems are from the host's point 
>>> of view, and whether they're the same.? (I don't know what this 
>>> might be, though!)
>>> 2. jcmd treats it as a heuristic and attempts each way during the 
>>> socket file read - first /proc/<pid>/root/tmp and then /tmp.
>>> 3. jcmd has some option or environment variable where the user can 
>>> tell it the socket file path.
>>>
>>> Do you agree that these are the types of choices available?
>>>
>>> Thanks,
>>> Jim
>>>
>>
>


From duke at openjdk.org  Thu May  2 10:22:51 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 2 May 2024 10:22:51 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <o4ihO2Qru4b6PC886yy-fh_HXMAYHu93Tj0NdDD6sw0=.17d8f4e1-38b5-4f0d-be18-3d3b8464b2c6@github.com>

On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

This is a first stab at fixing the regression introduced in #17628. There has been a bit of discussion in https://mail.openjdk.org/pipermail/serviceability-dev/2024-April/055317.html and https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055364.html about exactly how to solve it, but this first attempt requires quite few changes at least.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2090105068

From larry.cable at oracle.com  Thu May  2 10:30:48 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 2 May 2024 03:30:48 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container)
In-Reply-To: <o4ihO2Qru4b6PC886yy-fh_HXMAYHu93Tj0NdDD6sw0=.17d8f4e1-38b5-4f0d-be18-3d3b8464b2c6@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o4ihO2Qru4b6PC886yy-fh_HXMAYHu93Tj0NdDD6sw0=.17d8f4e1-38b5-4f0d-be18-3d3b8464b2c6@github.com>
Message-ID: <32410d49-63b1-4264-9e7b-8610d559c351@oracle.com>

using pid to namespace comparison is IMO inappropriate/misleading what 
is being tested is the sharing of a common mount namespace, therefore 
the test should be comparing the "mnt" namespace ids.

Rgds

- Larry

On 5/2/24 3:22 AM, Sebastian L?vdahl wrote:
> On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:
>
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
> This is a first stab at fixing the regression introduced in #17628. There has been a bit of discussion in https://mail.openjdk.org/pipermail/serviceability-dev/2024-April/055317.html and https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055364.html about exactly how to solve it, but this first attempt requires quite few changes at least.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2090105068


From duke at openjdk.org  Thu May  2 10:33:52 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 2 May 2024 10:33:52 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <axLkOR6Zn-L1n55YB_Uj30QuOeinVzplzlR7d4hvXNA=.cf4069d2-024a-4801-b1f2-089e0c8c140e@github.com>

On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Ran the following tests locally:


$ make test TEST="jtreg:test/hotspot/jtreg/containers"

...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/containers                  14    14     0     0   
==============================
TEST SUCCESS



$ make test TEST="jtreg:test/hotspot/jtreg/serviceability"

...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/serviceability             374   374     0     0   
==============================
TEST SUCCESS


And also manually tested it under various conditions. Basic environment information:


slovdahl at ubuntu2204:~/reproducer$ systemd --version
systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
slovdahl at ubuntu2204:~/reproducer$ sudo apt-get install openjdk-17-jdk-headless
slovdahl at ubuntu2204:~/reproducer$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)
slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
openjdk version "23-internal" 2024-09-17
OpenJDK Runtime Environment (build 23-internal-adhoc.slovdahl.jdk)
OpenJDK 64-Bit Server VM (build 23-internal-adhoc.slovdahl.jdk, mixed mode, sharing)


Reproducer.java used for the target process:


import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;

public class Reproducer {
  public static void main(String[] args) throws InterruptedException, IOException {
    int port;
    if (args.length > 0) {
      port = Integer.parseInt(args[0]);
    }
    else {
      port = 81;
    }

    System.out.println("Hello, World!");
    try (var server = new ServerSocket()) {
      server.bind(new InetSocketAddress("localhost", port));
      System.out.println("Bound to port " + port);
      while (true) {
        Thread.sleep(1_000L);
      }
    }
  }
}


systemd unit used for testing the fix for https://bugs.openjdk.org/browse/JDK-8226919:


slovdahl at ubuntu2204:~/reproducer$ cat reproducer.service
[Service]
Type=simple
ExecStart=/usr/lib/jvm/java-17-openjdk-amd64/bin/java /home/slovdahl/reproducer/Reproducer.java

User=slovdahl
Group=slovdahl
ReadWritePaths=/tmp
AmbientCapabilities=CAP_NET_BIND_SERVICE

slovdahl at ubuntu2204:~/reproducer$ sudo cp -a reproducer.service /etc/systemd/system/
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl daemon-reload
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl start reproducer.service
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl status reproducer.service 
? reproducer.service
     Loaded: loaded (/etc/systemd/system/reproducer.service; static)
     Active: active (running) since Wed 2024-05-01 20:22:01 EEST; 4s ago
   Main PID: 1576835 (java)
      Tasks: 26 (limit: 76968)
     Memory: 69.2M
        CPU: 832ms
     CGroup: /system.slice/reproducer.service
             ??1576835 /usr/lib/jvm/java-17-openjdk-amd64/bin/java /home/slovdahl/reproducer/Reproducer.java

maj 01 20:22:01 ubuntu2204 systemd[1]: Started reproducer.service.
maj 01 20:22:01 ubuntu2204 java[1576835]: Hello, World!
maj 01 20:22:01 ubuntu2204 java[1576835]: Bound to port 81

slovdahl at ubuntu2204:~/reproducer$ ls -lh /proc/1576835/root
ls: cannot read symbolic link '/proc/1576835/root': Permission denied
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  1 20:22 /proc/1576835/root
slovdahl at ubuntu2204:~/reproducer$ sudo ls -lh /proc/1576835/root
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  1 20:22 /proc/1576835/root -> /


Fails with vanilla OpenJDK 17:


slovdahl at ubuntu2204:~/reproducer$ /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd 1576835 VM.version
1576835:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /proc/1576835/root/tmp/.java_pid1576835: target process 1576835 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:104)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


Works when attaching as root with vanilla OpenJDK 17:


slovdahl at ubuntu2204:~/reproducer$ sudo /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd 1576835 VM.version
1576835:
OpenJDK 64-Bit Server VM version 17.0.10+7-Ubuntu-122.04.1
JDK 17.0.10


Still works without root with a JDK built from this PR (fixed in https://bugs.openjdk.org/browse/JDK-8226919):


slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 1576835 VM.version
1576835:
OpenJDK 64-Bit Server VM version 17.0.10+7-Ubuntu-122.04.1
JDK 17.0.10


Attaching to a JVM inside a Docker container from the host works as before with vanilla OpenJDK 17 and the JDK built from this PR (always requires root):


slovdahl at ubuntu2204:~/reproducer$ docker run --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81

slovdahl at ubuntu2204:~/reproducer$ sudo jcmd -l | grep Reproducer
1587278 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java

slovdahl at ubuntu2204:~/reproducer$ sudo /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd 1587278 VM.version
1587278:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

slovdahl at ubuntu2204:~/reproducer$ sudo /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 1587278 VM.version
1587278:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Attaching to the same Docker container JVM from a sidecar container mounted into the same process namespace:
- Attaching works with Temurin 17, but `jcmd -l` does not list the process
- Attaching and `jcmd -l` works with Temurin 21
- Attaching and listing fails with current mainline JDK
- Attaching and listing works with the fix in this PR


slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm --pid=container:great_curie eclipse-temurin:17.0.11_9-jdk-jammy /bin/bash
root at e8fa333f7f71:/# jcmd
326 jdk.jcmd/sun.tools.jcmd.JCmd
root at e8fa333f7f71:/# jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm --pid=container:great_curie eclipse-temurin:21.0.3_9-jdk-jammy /bin/bash
root at d7c84d951f3d:/# jcmd
384 jdk.jcmd/sun.tools.jcmd.JCmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
root at d7c84d951f3d:/# jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

# Mainline JDK
slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm --pid=container:great_curie --volume /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/:/jdk ubuntu:22.04 /bin/bash
root at 10595dab1b4d:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
443 jdk.jcmd/sun.tools.jcmd.JCmd
root at 10595dab1b4d:/# /jdk/bin/jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:99)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)

# JDK built from this PR
slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm --pid=container:great_curie --volume /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/:/jdk ubuntu:22.04 /bin/bash
root at 7b7ef4ba0b35:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
50 jdk.jcmd/sun.tools.jcmd.JCmd
root at 7b7ef4ba0b35:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2090136676

From ayang at openjdk.org  Thu May  2 10:54:03 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 May 2024 10:54:03 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection
Message-ID: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>

It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.

Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).

Test: tier1-6

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

Commit messages:
 - s1-do-collect

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331557
  Stats: 555 lines in 15 files changed: 123 ins; 347 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From jdoyle at iso-ne.com  Thu May  2 13:15:53 2024
From: jdoyle at iso-ne.com (Doyle, James, K)
Date: Thu, 2 May 2024 13:15:53 +0000
Subject: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>
References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com>
 <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com>
Message-ID: <b801dd0920c44f7bbd2f6eb4c94d1b50@iso-ne.com>

Thank you, Larry - that /proc/<pid>/ns/mnt test makes a lot of sense to me, and I learned something new today!

Jim

-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of Laurence Cable
Sent: Wednesday, May 1, 2024 8:44 PM
To: serviceability-dev at openjdk.org
Subject: Re: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

**Warning! This email originated from outside the organization. Do not open attachments unless you recognize the sender. If you suspect this email is malicious, use the "Report Email" button.
Replies to this email will go to serviceability-dev-retn at openjdk.org .**

just to demonstrate:

$ docker run -it --name=js1? openjdk:17.0.1-jdk? /bin/jshell ...
$ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 /bin/jshell


$ docker exec -it js1? bash
bash-4.4# ls /tmp/hsperfdata_root
1? 26
bash-4.4# readlink /proc/26/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/26/ns/mnt
mnt:[4026532747]
bash-4.4# exit
[lpgc at arran ~]$ docker exec -it js2? bash bash-4.4# ls /tmp/hsperfdata_root
107? 82
bash-4.4# readlink /proc/107/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/107/ns/mnt
mnt:[4026532941]

you will note that the JVM pid: 26 and 107 occupy the same pid namespace
(4026532751) but occupy different mnt namespaces (4026532747, 4026532941)

therefore attempting to attach via '/tmp' will fail, /proc/<pid>/root/tmp must be used to rendezvous

- Larry


On 5/1/24 2:03 PM, Doyle, James, K wrote:
> Hi Sebastian,
>
>> I think I can confirm that there is a regression.
> Thanks for reproducing the regression, your test makes sense to me, and I think it is similar to the scenario we have with Kubernetes debug containers (separate filesystems, but same PID namespace).
>
> I noticed some of the other recent Pull Request comments on https://github.com/openjdk/jdk/pull/17628:
>
>> should it not be comparing pid namespace ids and not pids?
> and wanted to give a little feedback.  I think more refined approaches to figuring out whether the target JVM is in the same PID namespace make sense and could be an improvement, but it's still different from figuring out whether the target JVM has the same filesystem (specifically, I guess, the filesystem containing /tmp or java.io.tmpdir).  That seems like the crucial thing for deciding what socket file path to read, and whether /tmp is sufficient or /proc/<pid>/root/tmp is needed.  I can think of a couple different approaches to the filesystem issue:
>
> 1. There is some Linux kernel information that can be obtained about 
> the jcmd process and the target JVM process to figure out unequivocally what their root filesystems are from the host's point of view, and whether they're the same.  (I don't know what this might be, though!) 2. jcmd treats it as a heuristic and attempts each way during the socket file read - first /proc/<pid>/root/tmp and then /tmp.
> 3. jcmd has some option or environment variable where the user can tell it the socket file path.
>
> Do you agree that these are the types of choices available?
>
> Thanks,
> Jim
>


From alanb at openjdk.org  Thu May  2 14:31:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 May 2024 14:31:55 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
Message-ID: <BG_QPlToqfbNu9pKqVQa4kpJ1vnADb3FoljxaYyZzt8=.36a4f404-7fcc-46ae-85fe-07483fa40ed7@github.com>

On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments

The update to the API specs looks okay. I think it was just a cut & paste error that the wrong text was copied into the description of the waiter_count and notify_waiter_count fields. I assume you'll update the CSR so it has the updated text.

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

PR Comment: https://git.openjdk.org/jdk/pull/19030#issuecomment-2090636854

From duke at openjdk.org  Thu May  2 14:33:09 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Thu, 2 May 2024 14:33:09 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v5]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <Jdl-CbWLbwOwL20VYcF5J6cmtCj1ZKuInQ_nbednKtc=.ab4aa57b-5d58-4c4b-845b-aba22dfa6ad9@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8330694
 - fix indentation
 - also tidy up
 - tidy up
 - rename

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

Changes: https://git.openjdk.org/jdk/pull/18871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18871&range=04
  Stats: 995 lines in 124 files changed: 0 ins; 4 del; 991 mod
  Patch: https://git.openjdk.org/jdk/pull/18871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18871/head:pull/18871

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

From duke at openjdk.org  Thu May  2 14:41:11 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Thu, 2 May 2024 14:41:11 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v6]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <0EiTktH1vdO-lzORVl-eklrn69deCe3IRr8fUHUYW1s=.02a0bd31-47a7-45ea-9fd4-63d4a7bee286@github.com>

> follow up 8267941

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/f4e066c4..92d0df4d

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

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

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

From shade at openjdk.org  Thu May  2 14:47:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 2 May 2024 14:47:18 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
Message-ID: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>

`CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).

Doing this rename separately guarantees we have caught and renamed all current uses.

Additional testing:
 - [ ] Linux AArch64 server fastdebug, `all`

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

Commit messages:
 - Fix

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

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

From stefank at openjdk.org  Thu May  2 17:08:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 2 May 2024 17:08:53 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all`

Seems like a good change.

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1270:

> 1268: 
> 1269:   ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
> 1270:   assert(!heap->is_stw_gc_active(), "not reentrant");

While reading this I see that all these "not reentrant" asserts seems redundant given that we already do these checks in `IsSTWGCActiveMark`. Brownies points if you get rid of them. ;)

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1493:

> 1491:   PCAddThreadRootsMarkingTaskClosure(uint worker_id) : _worker_id(worker_id) { }
> 1492:   void do_thread(Thread* thread) {
> 1493:     assert(ParallelScavengeHeap::heap()->is_stw_gc_active(), "called outside gc");

Should this be updated to "called outside gc pause" as you did in `G1CollectedHeap::pin_object`? The same comment goes for the other occurrences below.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19064#pullrequestreview-2036315901
PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1587988542
PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1587974562

From stefank at openjdk.org  Thu May  2 17:14:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 2 May 2024 17:14:55 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <168Z8R7UX0uYymkZ_NCW17QbrwLu_82rg0j4nJ895_E=.5e1c4624-770f-4e94-9588-797982c2cca9@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all`

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19064#pullrequestreview-2036349526

From shade at openjdk.org  Thu May  2 17:14:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 2 May 2024 17:14:57 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
 <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
Message-ID: <sAM_-0wLAjqg0oLKFM8WEJ-Pm6nQeCWciNMoXiiKP5k=.26db98db-d5b0-4281-b980-c85036b98ff7@github.com>

On Thu, 2 May 2024 16:56:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
>> 
>> Doing this rename separately guarantees we have caught and renamed all current uses.
>> 
>> Additional testing:
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1493:
> 
>> 1491:   PCAddThreadRootsMarkingTaskClosure(uint worker_id) : _worker_id(worker_id) { }
>> 1492:   void do_thread(Thread* thread) {
>> 1493:     assert(ParallelScavengeHeap::heap()->is_stw_gc_active(), "called outside gc");
> 
> Should this be updated to "called outside gc pause" as you did in `G1CollectedHeap::pin_object`? The same comment goes for the other occurrences below.

I deliberately stopped myself from doing this for Parallel GC code, where every GC is STW GC :) I can change to "GC pause" if you want.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1587999105

From shade at openjdk.org  Thu May  2 17:29:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 2 May 2024 17:29:52 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
 <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
Message-ID: <uhO3PJxmP13Eowq9xjkg_rg42uQhEet8jvvRDyGYnHo=.6c013ce1-aaeb-4f8d-b480-a4eb5fe39af9@github.com>

On Thu, 2 May 2024 17:04:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
>> 
>> Doing this rename separately guarantees we have caught and renamed all current uses.
>> 
>> Additional testing:
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1270:
> 
>> 1268: 
>> 1269:   ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
>> 1270:   assert(!heap->is_stw_gc_active(), "not reentrant");
> 
> While reading this I see that all these "not reentrant" asserts seems redundant given that we already do these checks in `IsSTWGCActiveMark`. Brownies points if you get rid of them. ;)

Ah, hm. Indeed! Separate PR? There is some light cleanup in G1 that can be associated with it. This PR would keep with just a mechanical rename.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1588015870

From stefank at openjdk.org  Thu May  2 17:29:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 2 May 2024 17:29:53 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <uhO3PJxmP13Eowq9xjkg_rg42uQhEet8jvvRDyGYnHo=.6c013ce1-aaeb-4f8d-b480-a4eb5fe39af9@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
 <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
 <uhO3PJxmP13Eowq9xjkg_rg42uQhEet8jvvRDyGYnHo=.6c013ce1-aaeb-4f8d-b480-a4eb5fe39af9@github.com>
Message-ID: <8rTp30vldMrfGYMh6uP-tirE9bjNGTBePOSztx95MD4=.8f9cdead-0301-42c4-acad-a2bfc26b4702@github.com>

On Thu, 2 May 2024 17:23:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1270:
>> 
>>> 1268: 
>>> 1269:   ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
>>> 1270:   assert(!heap->is_stw_gc_active(), "not reentrant");
>> 
>> While reading this I see that all these "not reentrant" asserts seems redundant given that we already do these checks in `IsSTWGCActiveMark`. Brownies points if you get rid of them. ;)
>
> Ah, hm. Indeed! Separate PR? There is some light cleanup in G1 that can be associated with it. This PR would keep with just a mechanical rename.

Sounds like a good idea.

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1493:
>> 
>>> 1491:   PCAddThreadRootsMarkingTaskClosure(uint worker_id) : _worker_id(worker_id) { }
>>> 1492:   void do_thread(Thread* thread) {
>>> 1493:     assert(ParallelScavengeHeap::heap()->is_stw_gc_active(), "called outside gc");
>> 
>> Should this be updated to "called outside gc pause" as you did in `G1CollectedHeap::pin_object`? The same comment goes for the other occurrences below.
>
> I deliberately stopped myself from doing this for Parallel GC code, where every GC is STW GC :) I can change to "GC pause" if you want.

Ah, I see. I wouldn't mind if it were changed to include "pause", but I'm also OK with you leaving it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1588019866
PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1588018382

From zgu at openjdk.org  Thu May  2 17:34:52 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 2 May 2024 17:34:52 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <tWHvsp_5iUx05gPof-L85Lk39aHhDECdwzT2kl2-Mfg=.c0bceceb-08d8-42f0-ab5f-bd11569b4223@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all`

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19064#pullrequestreview-2036411170

From sspitsyn at openjdk.org  Thu May  2 17:47:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 May 2024 17:47:54 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
Message-ID: <-vAMg5Qz5ofCPtk7lYfp1fsmg98Rk_MpdiHHHK_rN5g=.2b836e19-d999-48bb-a778-1a0efeb17079@github.com>

On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments

Thank you, Alan. I've updated the CSR with the recent diffs.
Also, added a statement about separate deprecation plans.

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

PR Comment: https://git.openjdk.org/jdk/pull/19030#issuecomment-2091156003

From amenkov at openjdk.org  Thu May  2 19:41:56 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 May 2024 19:41:56 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>

On Wed, 1 May 2024 21:32:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

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

> 654:     commonRef_lock();
> 655:     if (gdata->rankedMonitors) {
> 656:         dbgRawMonitor_lock();

What is this call for? I think dbgRawMonitor_lock/dbgRawMonitor_unlock should not be used outside of util.c (I'd remove them from util.h)

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1204:

> 1202:     // Need to lock during initialization so verifyMonitorRank() can be guaranteed that
> 1203:     // if the monitor field is set, then the monitor if fully initialized. More specifically,
> 1204:     // that the rank field has been set.

rank for all monitors can be set in `util_initialize()`:

for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
  dbg_monitors[i]->rank = i;
}

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1231:

> 1229:     }
> 1230: 
> 1231:     dbg_monitor->monitor = NULL;

I think it would be better to protect this with dbgRawMonitor

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1243:

> 1241:     error = JVMTI_FUNC_PTR(gdata->jvmti,GetThreadInfo)
> 1242:             (gdata->jvmti, thread, &info);
> 1243:     return info.name;

Need to delete JNI reference info.thread_group and info.jthreadGroup (if not NULL)

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1262:

> 1260:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
> 1261:         DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
> 1262:         if (dbg_monitor == NULL) {

Should be `dbg_monitor->monitor`

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1279:

> 1277:         return; // This assert is not reliable if the VM is exiting
> 1278:     }
> 1279:     jthread current_thread = threadControl_currentThread();

Looks like all callers of the `assertIsCurrentThread()` have reference to the current thread. Maybe pass it as argument?

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1281:

> 1279:     jthread current_thread = threadControl_currentThread();
> 1280:     if (!isSameObject(env, thread, current_thread)) {
> 1281:         tty_message("ERROR: Threads not the same: %p %p\n", thread, current_thread);

Not sure the addresses provide useful information. Maybe print thread names?

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1289:

> 1287: 
> 1288: static void
> 1289: verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread thread)

please add a comment that the function should be called under dbgRawMonitor lock (also for other functions which assume this)

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1294:

> 1292:     // has a higher rank than the monitor we are about to enter.
> 1293:     DebugRawMonitorRank i;
> 1294:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {

No need to check monitors from the beginning.
Should be enough to check starting from `min(rank, FIRST_LEAF_DEBUG_RAW_MONITOR)`

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1470:

> 1468: 
> 1469:     // Assert that the current thread owns this monitor.
> 1470:     assertIsCurrentThread(getEnv(), dbg_monitor->ownerThread);

reading ownerThread (and other) fields without dbgRawMonitor is not MT-safe (it's not atomic)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586999913
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588259933
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586968454
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586970362
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586973059
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586983415
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586984623
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588206582
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1586976698
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588252771

From amenkov at openjdk.org  Thu May  2 21:24:58 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 May 2024 21:24:58 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v6]
In-Reply-To: <oKw_lwvggGR1lO90lIqvwzDVsV0Qqp0heQgm-TGdFjU=.a27a162d-b28f-4b22-9a3d-3d185666ddac@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <oKw_lwvggGR1lO90lIqvwzDVsV0Qqp0heQgm-TGdFjU=.a27a162d-b28f-4b22-9a3d-3d185666ddac@github.com>
Message-ID: <c5UzUHtFRkDt78ogzEYYR9bU9zAaSvUIoeQnqKXNIWc=.53a8d804-2092-4c40-ab8e-0fdebd6ff112@github.com>

On Tue, 30 Apr 2024 18:54:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed space-only change in diagnosticCommand.cpp

Currently heap dump is always performed in 2 phases (even if single threaded heap dump is requested or SerialGC is used). This is required to correctly handle unmounted virtual threads.
This was implemented in jdk22, so your testing shows regression comparing with jdk21u (which does not dump unmounted vthreads and references from them).
Note also that you use `-XX:+HeapDumpAfterFullGC` in your testing and look at total heap dump time.
Main advantage of the 2 phase dumping is decreasing STW time (merge phase is performed on the current thread outside of safepoint). I.e. the idea is not  to decrease total heap dump time, but to minimize JVM freeze during dumping.
But this does not work in case of -XX:+HeapDumpBeforeFullGC and -XX:+HeapDumpAfterFullGC because heap dumping is requested inside safepoint, so merge stage is also performed in safepoint too (I think it's possible to fix it so merge is performed on some other thread, but I'm not sure it worth it).

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

PR Comment: https://git.openjdk.org/jdk/pull/18748#issuecomment-2091683903

From cjplummer at openjdk.org  Thu May  2 21:29:56 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:29:56 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
In-Reply-To: <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
Message-ID: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>

On Thu, 2 May 2024 02:40:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 656:
> 
>> 654:     commonRef_lock();
>> 655:     if (gdata->rankedMonitors) {
>> 656:         dbgRawMonitor_lock();
> 
> What is this call for? I think dbgRawMonitor_lock/dbgRawMonitor_unlock should not be used outside of util.c (I'd remove them from util.h)

After calling getLocks(), there may still be attempts to enter locks. The locks should already be held. I filed [JDK-8330193](https://bugs.openjdk.org/browse/JDK-8330193) to assert that. However, even when entering an already entered lock, we still need to grab dbgRawMonitor. I found that out the hard way when there were deadlocks on dbgRawMonitor because it was not entered it here.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1204:
> 
>> 1202:     // Need to lock during initialization so verifyMonitorRank() can be guaranteed that
>> 1203:     // if the monitor field is set, then the monitor if fully initialized. More specifically,
>> 1204:     // that the rank field has been set.
> 
> rank for all monitors can be set in `util_initialize()`:
> 
> for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
>   dbg_monitors[i]->rank = i;
> }

Ok.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1231:
> 
>> 1229:     }
>> 1230: 
>> 1231:     dbg_monitor->monitor = NULL;
> 
> I think it would be better to protect this with dbgRawMonitor

I don't see how that helps. Access to the field is not protected.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1243:
> 
>> 1241:     error = JVMTI_FUNC_PTR(gdata->jvmti,GetThreadInfo)
>> 1242:             (gdata->jvmti, thread, &info);
>> 1243:     return info.name;
> 
> Need to delete JNI reference info.thread_group and info.jthreadGroup (if not NULL)

Did you mean info.context_class_loader, not info.jthreadGroup?

It looks like elsewhere when we call GetThreadInfo it is bracketed with the WITH_LOCAL_REFS macro to automatically push/pop a local refs frame, although it is only setting the size to 1, which seems like a bug. I'll do the same here.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1262:
> 
>> 1260:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
>> 1261:         DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
>> 1262:         if (dbg_monitor == NULL) {
> 
> Should be `dbg_monitor->monitor`

ok

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1279:
> 
>> 1277:         return; // This assert is not reliable if the VM is exiting
>> 1278:     }
>> 1279:     jthread current_thread = threadControl_currentThread();
> 
> Looks like all callers of the `assertIsCurrentThread()` have reference to the current thread. Maybe pass it as argument?

Ok. There were a few changes w.r.t. when this API is called, as was when the callers have access to the current thread, so I that's why I ended up not passing it in.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1281:
> 
>> 1279:     jthread current_thread = threadControl_currentThread();
>> 1280:     if (!isSameObject(env, thread, current_thread)) {
>> 1281:         tty_message("ERROR: Threads not the same: %p %p\n", thread, current_thread);
> 
> Not sure the addresses provide useful information. Maybe print thread names?

ok

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1289:
> 
>> 1287: 
>> 1288: static void
>> 1289: verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread thread)
> 
> please add a comment that the function should be called under dbgRawMonitor lock (also for other functions which assume this)

ok. I was also thinking of setting a static that contains the jthread of the thread that holds the lock, and we can assert it is held.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1294:
> 
>> 1292:     // has a higher rank than the monitor we are about to enter.
>> 1293:     DebugRawMonitorRank i;
>> 1294:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
> 
> No need to check monitors from the beginning.
> Should be enough to check starting from `min(rank, FIRST_LEAF_DEBUG_RAW_MONITOR)`

I originally started at `rank`, but then when I added the 2nd of the two checks below I switched to 0, but your min suggestion should be optimal.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1470:
> 
>> 1468: 
>> 1469:     // Assert that the current thread owns this monitor.
>> 1470:     assertIsCurrentThread(getEnv(), dbg_monitor->ownerThread);
> 
> reading ownerThread (and other) fields without dbgRawMonitor is not MT-safe (it's not atomic)

It is safe if you are the owner of the monitor.  So what that means is that this assert could potentially crash, but only if you are not the owner, which means if it didn't crash then it would have asserted. However, even when asserts are disabled, isSameObject() is still executed, and that's were the crash would happen. assertIsCurrentThread() really should be a no-op if asserts are not enabled. But even if that change is not made, it still would only crash if something bad was going on since the current thread should always own the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588360985
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588367723
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588371240
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588390369
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588391447
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588394746
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588397148
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588400113
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588407481
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1588424198

From cjplummer at openjdk.org  Thu May  2 21:35:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:35:54 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v6]
In-Reply-To: <cEoQBkFrlJvXTqNd0R1YETghp7tXpfL7h7fSF0nFXU0=.8ad29c60-7742-4f97-a045-fb7b2dd7cac8@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cEoQBkFrlJvXTqNd0R1YETghp7tXpfL7h7fSF0nFXU0=.8ad29c60-7742-4f97-a045-fb7b2dd7cac8@github.com>
Message-ID: <7mbaVxLkGeEnczjYFmrAtu3vtwdZmZxgH06ZxAradkY=.e8ff6e41-4fea-4517-86d3-89f432b37ccd@github.com>

On Sat, 20 Apr 2024 03:04:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java line 131:
> 
>> 129:   }
>> 130: 
>> 131:   public G1HeapRegion getHeapRegion() {
> 
> Do we want to rename to getG1HeapRegion?

It seems you agreed with this suggestion but the change was never made.

> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java line 62:
> 
>> 60:             agent.attach(Integer.parseInt(pid));
>> 61:             G1CollectedHeap heap = (G1CollectedHeap)VM.getVM().getUniverse().heap();
>> 62:             G1HeapRegion hr = heap.hrm().heapRegionIterator().next();
> 
> "g1HeapRegionIterator"?

And here also it seems you agreed with this suggestion but the change was never made.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1588433200
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1588434351

From cjplummer at openjdk.org  Thu May  2 21:38:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:38:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
Message-ID: <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>

On Thu, 2 May 2024 06:45:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 257:
>> 
>>> 255:             // Correct the expected values for the virtual thread case.
>>> 256:             int expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS;
>>> 257:             int expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS;
>> 
>> There are comments below that still reference NUMBER_OF_ENTERING_THREADS  and NUMBER_OF_WAITING_THREADS.
>
> Thank you for the comment. In fact, I don't know how to fix it.
> Replacing of NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in comments with `expEnteringCount/expWaitingCount` does not make sense to me. The comments are about the tested pattern, not about the real values. Please, let me know if you have any suggestion on fixing.

expEnteringCount/expWaitingCount contain the tested patterns. I don't see why they can't just replace NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in the comments also. In fact it is confusing if you don't because code right below the comments references expEnteringCount/expWaitingCount, not NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1588440431

From cjplummer at openjdk.org  Thu May  2 21:52:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:52:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
Message-ID: <r4yW9bqMaQ9GdJNTz2zdjY4DzCTrLJxFOkMYPjPdoiM=.26e66114-f754-4080-aff5-39135b1bf253@github.com>

On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments

src/hotspot/share/prims/jvmti.xml line 8280:

> 8278:           <description>
> 8279:             The number of platform threads waiting to own this monitor, or <code>0</code>
> 8280:             if only virtual threads are waiting or no threads are waiting

This is now exactly the same as `waiter_count` above. I don't think this is what you intended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1588453160

From cjplummer at openjdk.org  Thu May  2 21:52:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:52:55 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
Message-ID: <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>

On Thu, 2 May 2024 21:36:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thank you for the comment. In fact, I don't know how to fix it.
>> Replacing of NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in comments with `expEnteringCount/expWaitingCount` does not make sense to me. The comments are about the tested pattern, not about the real values. Please, let me know if you have any suggestion on fixing.
>
> expEnteringCount/expWaitingCount contain the tested patterns. I don't see why they can't just replace NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in the comments also. In fact it is confusing if you don't because code right below the comments references expEnteringCount/expWaitingCount, not NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS.

...and there are also comments above with this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1588456637

From cjplummer at openjdk.org  Thu May  2 21:52:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:52:54 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <sF24teBZ59vbwasns9jG3Bd6qNO2MD04fqBaT2h-rL4=.3cbee8f2-a6a8-4952-b04a-143e87155348@github.com>

On Wed, 1 May 2024 20:42:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments
>
> src/java.se/share/data/jdwp/jdwp.spec line 1622:
> 
>> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
>> 1621:                                 "if owned` by a virtual thread or not owned.")
>> 1622:             (int entryCount "The number of times the owning platform thread has entered the monitor.")
> 
> See the comment I left for the JVMTI spec. We should be more complete in the explanation here, explaining how it is 0 for virtual threads.

I don't think this has been resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1588459462

From cjplummer at openjdk.org  Thu May  2 21:58:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:58:53 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v3]
In-Reply-To: <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
Message-ID: <p2yrPj5u_YyeY90EADjDw9_OpqKmXQ8qq3IBvv1A_LU=.ba6e467c-385c-4c35-b2de-fe1dfa85f3ee@github.com>

On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review - DaemonThreadTest.java, no need for checking if thread is virtual

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19016#pullrequestreview-2037020145

From cjplummer at openjdk.org  Thu May  2 21:58:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 21:58:55 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <8Xpm3fH_1mWw283vz0-cQAzLc5D3gUHedRsSC0Eb6zY=.8e2672a3-d81b-4d3d-8fe1-a04fb221a3aa@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
 <x9F_WHYkU1px_6kOdiQAxTbCPKvF8NhI_Q4AV6wZSe8=.bfea087b-13cb-466a-91d8-05bc01d36ca1@github.com>
 <8Xpm3fH_1mWw283vz0-cQAzLc5D3gUHedRsSC0Eb6zY=.8e2672a3-d81b-4d3d-8fe1-a04fb221a3aa@github.com>
Message-ID: <xYx9W2d5vSh9KuMG_3GdaNLKYTvgLI3Tw9OqexVdOVQ=.e5984327-be3a-44ec-a860-f1e578423c22@github.com>

On Thu, 2 May 2024 03:57:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java line 77:
>> 
>>> 75:             t.setDaemon(false);
>>> 76:         }
>>> 77:         testThread(t, "");
>> 
>> I think the following is a bit clearer:
>> 
>> 
>> // Virtual threads are always daemon threads. Therefore if the current thread is a
>> // virtual thread, then NormalThread will be a daemon thread and we need to explicitly
>> // make it not a daemon thread.
>> 
>> 
>> You don't actually need the isVirtual() check, especially with the comment explaining things. However, you could also forgo all this logic and the comment by just sticking setDaemon(false) in the NormalThread constructor.
>
> Done - I've updated the PR to just call `setDaemon(false)`  from the constructor of `NormalThread` instead of this conditional logic.
> 
> When I initially added this logic, I was trying to avoid doing any changes that could impact the testing when running under platform threads. But thinking about this test's context, it merely wants to verify that the jstack output correctly presents daemon/non-daemon status, so explicitly setting a "normal" thread to non-daemon shouldn't impact what this test was originally verifying.

Yes, I also briefly wondered if somehow this would be subverting the testing of whether the thread was not daemon by default, but that's not what is being tested here.

>> test/jdk/sun/tools/jstack/BasicJStackTest.java line 53:
>> 
>>> 51:             // print the stacktraces of virtual threads.
>>> 52:             throw new SkippedException("skipping test since current thread is a virtual thread");
>>> 53:         }
>> 
>> I wonder if we can rely on the virtual thread always be mounted. If so, we could revisit this test after [JDK-8330846](https://bugs.openjdk.org/browse/JDK-8330846) is implemented.
>
> Hello Chris, if I understand that JBS issue correctly, then by default jstack (and other tools) will start including stacktraces of virtual threads that currently are mounted on a carrier thread (and thus haven't been parked) in the output.
> 
> If that's the case, then I think when that JBS issue is implemented we can remove this conditional check and the skipping of the test since the virtual thread would end up appearing in the thread dump because that's the thread which would be currently launching the `jstack` process and waiting (through a `ReentrantLock`'s `Condition` object) for the jstack process to complete.
> 
> To revisit this test when JDK-8330846 is implemented, do you want me to file an issue? Or did you mean we should wait doing the changes in this PR until JDK-8330846 is implemented?

I think just noting this in [JDK-8330846](https://bugs.openjdk.org/browse/JDK-8330846) should be good enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1588463768
PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1588462528

From larry.cable at oracle.com  Thu May  2 22:33:28 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 2 May 2024 15:33:28 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container)
In-Reply-To: <axLkOR6Zn-L1n55YB_Uj30QuOeinVzplzlR7d4hvXNA=.cf4069d2-024a-4801-b1f2-089e0c8c140e@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <axLkOR6Zn-L1n55YB_Uj30QuOeinVzplzlR7d4hvXNA=.cf4069d2-024a-4801-b1f2-089e0c8c140e@github.com>
Message-ID: <718b8639-8d1a-4d8e-b7f0-e330447fd2be@oracle.com>

diff --git 
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
b/src/jdk.attach/linux/classes/sun/tools/attach/V
irtualMachineImpl.java
index 81d4fd259ed..74bd60c791d 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -34,6 +34,7 @@
 ?import java.nio.file.Path;
 ?import java.nio.file.Paths;
 ?import java.nio.file.Files;
+import java.util.Optional;

 ?import static java.nio.charset.StandardCharsets.UTF_8;

@@ -47,7 +48,21 @@ public class VirtualMachineImpl extends 
HotSpotVirtualMachine {
 ???? // will not be able to find all Hotspot processes.
 ???? // Any changes to this needs to be synchronized with HotSpot.
 ???? private static final String tmpdir = "/tmp";
+
+??? private static final Optional<Path> MOUNT_NS;
+
+??? static {
+??????? Path mountns = null;
+??????? try {
+??????????? mountns = Files.readSymbolicLink(Path.of("/proc/self/ns/mnt"));
+??????? } catch (IOException ioe) {
+??????? } finally {
+??????????? MOUNT_NS = Optional.ofNullable(mountns);
+??????? }
+??? }
+
 ???? String socket_path;
+
 ???? /**
 ????? * Attaches to the target VM
 ????? */
@@ -236,7 +251,18 @@ private File createAttachFile(int pid, int ns_pid) 
throws IOException {

 ???? private String findTargetProcessTmpDirectory(int pid, int ns_pid) 
throws IOException {
 ???????? String root;
-??????? if (pid != ns_pid) {
+
+??????? Optional<Path> tgtMountNS = Optional.empty();
+
+??????? try {
+??????????? tgtMountNS = 
Optional.ofNullable(Files.readSymbolicLink(Path.of("/proc", 
Integer.toString(pid), "ns", "mnt")));
+??????? } catch (IOException _) {
+????????? // do nothing...
+??????? }
+
+??? final boolean sameMountNS = MOUNT_NS.isPresent() && 
tgtMountNS.isPresent() && MOUNT_NS.equals(tgtMountNS);
+
+??????? if (!sameMountNS || pid != ns_pid) {
 ???????????? // A process may not exist in the same mount namespace as 
the caller, e.g.
 ???????????? // if we are trying to attach to a JVM process inside a 
container.
 ???????????? // Instead, attach relative to the target root filesystem 
as exposed by
@@ -248,11 +274,11 @@ private String findTargetProcessTmpDirectory(int 
pid, int ns_pid) throws IOExcep
 ?????????????????????????? "of target process %d", procRootDirectory, 
pid));
 ???????????? }

-??????????? root = procRootDirectory + "/" + tmpdir;
-??????? } else {
-??????????? root = tmpdir;
-??????? }
-??????? return root;
+??????????? return procRootDirectory + "/" + tmpdir;
+??????? } else if (sameMountNS) {
+??????????? return tmpdir;
+??????? } else
+??? ??? throw new IOException(String.format("target process:%d and this 
do not share common mount namespace for: %s attach faile
d", pid, tmpdir));
 ???? }

 ???? /*


From cjplummer at openjdk.org  Thu May  2 22:42:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 22:42:52 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <kjiPCOWNS20g8J6Nxg3SgWStVoA4_je72IIuyrpWBTs=.a2cf12dc-e186-442f-8194-7d6b60a4e97d@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

I looked at other places where the following is already in place:

`return; // no events should be posted if thread is in any VTMS transition`

I can understand the rationale for not sending events in those cases (like breakpoint, singlestep, and methodentry). However, loss ClassPrepare and ClassLoad events seems a bit more significant for profilers that might be trying to accurately track all class loading. It seems maybe we should instead be trying to avoid these events by preloading the classes as was suggested as an option in the CR.

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

PR Review: https://git.openjdk.org/jdk/pull/19054#pullrequestreview-2037080382

From cjplummer at openjdk.org  Thu May  2 22:46:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 May 2024 22:46:52 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v3]
In-Reply-To: <lNh5HCmBBIGyDubznqoEP5cWGxeRpEKQFdY5JbwgJ2c=.8f2a07e4-d73a-49ea-a8a9-f49f0a8567c5@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <lNh5HCmBBIGyDubznqoEP5cWGxeRpEKQFdY5JbwgJ2c=.8f2a07e4-d73a-49ea-a8a9-f49f0a8567c5@github.com>
Message-ID: <7DToDczTkXlyv-tvpHtlVJA33LDsAfV_2t7uzQ5SNSI=.b68b2474-eb3e-4e89-a84f-42403104585a@github.com>

On Tue, 30 Apr 2024 23:48:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed current_thread tp current

Given the number of `current` renames (which distracts from the core change in this PR), and given that not all occurrences were renamed (only those that were touched), I think it would be best to leave the rename for a separate PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18986#issuecomment-2091868298

From amenkov at openjdk.org  Thu May  2 23:58:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 May 2024 23:58:52 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v3]
In-Reply-To: <lNh5HCmBBIGyDubznqoEP5cWGxeRpEKQFdY5JbwgJ2c=.8f2a07e4-d73a-49ea-a8a9-f49f0a8567c5@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <lNh5HCmBBIGyDubznqoEP5cWGxeRpEKQFdY5JbwgJ2c=.8f2a07e4-d73a-49ea-a8a9-f49f0a8567c5@github.com>
Message-ID: <5jmKQ3eqaYVEG5niaFpjNT4F4wKyjufHXTv_AbWTp2U=.7df58d35-552a-4677-ac59-8902ef4ad42c@github.com>

On Tue, 30 Apr 2024 23:48:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed current_thread tp current

ok, I'll revert last update and rename current_thread to current only in few places where new variable is introduced

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

PR Comment: https://git.openjdk.org/jdk/pull/18986#issuecomment-2091927214

From amenkov at openjdk.org  Fri May  3 01:54:24 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 3 May 2024 01:54:24 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v4]
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:

 - update
 - Revert "renamed current_thread to current"
   
   This reverts commit d5d614bcf0861466acd695296e974d2253f84c9f.
 - Revert "renamed current_thread tp current"
   
   This reverts commit 4602632221044aa754a1bc8d11e7a3e9a0092590.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18986/files
  - new: https://git.openjdk.org/jdk/pull/18986/files/46026322..9be24a4a

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

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

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

From duke at openjdk.org  Fri May  3 06:24:54 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 3 May 2024 06:24:54 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v6]
In-Reply-To: <7mbaVxLkGeEnczjYFmrAtu3vtwdZmZxgH06ZxAradkY=.e8ff6e41-4fea-4517-86d3-89f432b37ccd@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cEoQBkFrlJvXTqNd0R1YETghp7tXpfL7h7fSF0nFXU0=.8ad29c60-7742-4f97-a045-fb7b2dd7cac8@github.com>
 <7mbaVxLkGeEnczjYFmrAtu3vtwdZmZxgH06ZxAradkY=.e8ff6e41-4fea-4517-86d3-89f432b37ccd@github.com>
Message-ID: <7xbz4cpe2Je-WAWeZ17YSu05m93hGEUarw4YwvNqF50=.11095cda-d9ae-439e-8884-0f36ef7ef58d@github.com>

On Thu, 2 May 2024 21:32:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java line 62:
>> 
>>> 60:             agent.attach(Integer.parseInt(pid));
>>> 61:             G1CollectedHeap heap = (G1CollectedHeap)VM.getVM().getUniverse().heap();
>>> 62:             G1HeapRegion hr = heap.hrm().heapRegionIterator().next();
>> 
>> "g1HeapRegionIterator"?
>
> And here also it seems you agreed with this suggestion but the change was never made.

I think we can make these changes in later PRs in order to avoid making this one even larger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1588784617

From alanb at openjdk.org  Fri May  3 06:42:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 May 2024 06:42:55 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <r4yW9bqMaQ9GdJNTz2zdjY4DzCTrLJxFOkMYPjPdoiM=.26e66114-f754-4080-aff5-39135b1bf253@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
 <r4yW9bqMaQ9GdJNTz2zdjY4DzCTrLJxFOkMYPjPdoiM=.26e66114-f754-4080-aff5-39135b1bf253@github.com>
Message-ID: <HFSodX-FNKGVZcPk_ttwEmYYQB6HI-IrdYoYvMuMZPI=.3dcd0b09-38bc-4768-93b7-b557e8d6eb9b@github.com>

On Thu, 2 May 2024 21:44:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3) test comments
>
> src/hotspot/share/prims/jvmti.xml line 8280:
> 
>> 8278:           <description>
>> 8279:             The number of platform threads waiting to own this monitor, or <code>0</code>
>> 8280:             if only virtual threads are waiting or no threads are waiting
> 
> This is now exactly the same as `waiter_count` above. I don't think this is what you intended.

Indeed, looks like the description for waiter_count has been pasted in here in error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1588796716

From tschatzl at openjdk.org  Fri May  3 06:48:52 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 3 May 2024 06:48:52 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v6]
In-Reply-To: <7xbz4cpe2Je-WAWeZ17YSu05m93hGEUarw4YwvNqF50=.11095cda-d9ae-439e-8884-0f36ef7ef58d@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cEoQBkFrlJvXTqNd0R1YETghp7tXpfL7h7fSF0nFXU0=.8ad29c60-7742-4f97-a045-fb7b2dd7cac8@github.com>
 <7mbaVxLkGeEnczjYFmrAtu3vtwdZmZxgH06ZxAradkY=.e8ff6e41-4fea-4517-86d3-89f432b37ccd@github.com>
 <7xbz4cpe2Je-WAWeZ17YSu05m93hGEUarw4YwvNqF50=.11095cda-d9ae-439e-8884-0f36ef7ef58d@github.com>
Message-ID: <7cYZUtNt8Xl8sjIWBNpspMhLR-XUaimVawGI2f5j57g=.8cdbc54e-4f85-4526-bba8-35432e82a1ce@github.com>

On Fri, 3 May 2024 06:21:54 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> And here also it seems you agreed with this suggestion but the change was never made.
>
> I think we can make these changes in later PRs in order to avoid making this one even larger.

As mentioned earlier, I also think the SA changes should be done here in this CR since they are fairly minor and related to single methods, so not as encapsulated as changes to the remaining class names (for which I already created an RFR https://bugs.openjdk.org/browse/JDK-8331385).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1588800658

From alanb at openjdk.org  Fri May  3 06:51:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 May 2024 06:51:51 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <kjiPCOWNS20g8J6Nxg3SgWStVoA4_je72IIuyrpWBTs=.a2cf12dc-e186-442f-8194-7d6b60a4e97d@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
 <kjiPCOWNS20g8J6Nxg3SgWStVoA4_je72IIuyrpWBTs=.a2cf12dc-e186-442f-8194-7d6b60a4e97d@github.com>
Message-ID: <w-oxxnLs-wQjbAdZgnzzebtHNBbSEFGf9H2nfBDmmiw=.ba32b36e-6106-4dd9-8d52-ad1318ca8514@github.com>

On Thu, 2 May 2024 22:40:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It seems maybe we should instead be trying to avoid these events by preloading the classes as was suggested as an option in the CR.

I don't think preloading PinnedThreadPrinter will solve it completely. First usage could potentially load a lot of other classes, e.g. the current implementation uses streams and several other APIs. Going forward, this debugging option should be removed. It's already removed in the loom repo. It has been the source of several issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2092406784

From tschatzl at openjdk.org  Fri May  3 06:52:51 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 3 May 2024 06:52:51 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <bvCWv2N2-pnOGovIGFFPv2hyh1_ecNCi7IZ3dxe8R8Q=.709d2162-a8f7-4c42-bcee-caf828685f04@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all`

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19064#pullrequestreview-2037494618

From gli at openjdk.org  Fri May  3 08:20:53 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 3 May 2024 08:20:53 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <gEuar5Ns3svYSr0PsBbs5cVO_xJefh91YeuZl7APpBU=.be7f4e1c-05cb-4c4b-8a20-f3988e0f17af@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all`

Looks good.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19064#pullrequestreview-2037637061

From sspitsyn at openjdk.org  Fri May  3 09:02:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 May 2024 09:02:54 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <w-oxxnLs-wQjbAdZgnzzebtHNBbSEFGf9H2nfBDmmiw=.ba32b36e-6106-4dd9-8d52-ad1318ca8514@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
 <kjiPCOWNS20g8J6Nxg3SgWStVoA4_je72IIuyrpWBTs=.a2cf12dc-e186-442f-8194-7d6b60a4e97d@github.com>
 <w-oxxnLs-wQjbAdZgnzzebtHNBbSEFGf9H2nfBDmmiw=.ba32b36e-6106-4dd9-8d52-ad1318ca8514@github.com>
Message-ID: <4W4NxkWeMMZng4oTDBWpJp3glMe-fy0onT-G-KRi-Q0=.28368d7b-0219-41bd-a37b-69d5f8880808@github.com>

On Fri, 3 May 2024 06:49:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It seems maybe we should instead be trying to avoid these events by preloading the classes as was suggested as an option in the CR.

The problem is that all such cases are unknown, so it is just not realistic. As Alan commented, this exact debugging option will be removed soon. The other cases are extremely rare because they were not identified with the assert in place (in fact, these assert existed for a couple of releases for exactly this purpose). However, such classes can cause real problems (deadlocks and other issues as we see) if they are not ignored by `CFLH`, `ClassPrepare` and `ClassLoad` posting code.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2092596008

From sspitsyn at openjdk.org  Fri May  3 10:33:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 May 2024 10:33:53 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v2]
In-Reply-To: <HFSodX-FNKGVZcPk_ttwEmYYQB6HI-IrdYoYvMuMZPI=.3dcd0b09-38bc-4768-93b7-b557e8d6eb9b@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YV_-RKyZBRdcxEQr-14JXCCg4TQRFcG4ZEZAJStAJdc=.4f03038e-71b0-4b8e-9ece-d29ff5e8896d@github.com>
 <r4yW9bqMaQ9GdJNTz2zdjY4DzCTrLJxFOkMYPjPdoiM=.26e66114-f754-4080-aff5-39135b1bf253@github.com>
 <HFSodX-FNKGVZcPk_ttwEmYYQB6HI-IrdYoYvMuMZPI=.3dcd0b09-38bc-4768-93b7-b557e8d6eb9b@github.com>
Message-ID: <TWZZkLJetdD1jYc6u0PmwsfXUGo4OO48b7sB9R552uw=.4dceb10a-1387-4c21-8ecd-7d805a69dc51@github.com>

On Fri, 3 May 2024 06:40:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 8280:
>> 
>>> 8278:           <description>
>>> 8279:             The number of platform threads waiting to own this monitor, or <code>0</code>
>>> 8280:             if only virtual threads are waiting or no threads are waiting
>> 
>> This is now exactly the same as `waiter_count` above. I don't think this is what you intended.
>
> Indeed, looks like the description for waiter_count has been pasted in here in error.

Thank you.
Fixed as below:

diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml
index d382a02178e..3bcf15466d7 100644
--- a/src/hotspot/share/prims/jvmti.xml
+++ b/src/hotspot/share/prims/jvmti.xml
@@ -8277,7 +8277,8 @@ class C2 extends C1 implements I2 {
           <jint/>
           <description>
             The number of platform threads waiting to own this monitor, or <code>0</code>
-            if only virtual threads are waiting or no threads are waiting
+            if only virtual threads are waiting to be notified or no threads are waiting
+            to be notified
           </description>
         </field>
         <field id="notify_waiters">

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1589031880

From sspitsyn at openjdk.org  Fri May  3 10:53:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 May 2024 10:53:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <2ou2F-YXLZM2QCxGp86nhs-GBwDG4hfHvwrKMRxal84=.0c26f8c5-99fb-4b84-b19f-490e68c8c4fa@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: tweaks in JVMTI and JDWP changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/7465f064..e7c2d652

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

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

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

From sspitsyn at openjdk.org  Fri May  3 10:53:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 May 2024 10:53:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
 <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
Message-ID: <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>

On Thu, 2 May 2024 21:47:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> expEnteringCount/expWaitingCount contain the tested patterns. I don't see why they can't just replace NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in the comments also. In fact it is confusing if you don't because code right below the comments references expEnteringCount/expWaitingCount, not NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS.
>
> ...and there are also comments above with this issue.

> expEnteringCount/expWaitingCount contain the tested patterns.

I kind of disagree.
Please, take look at the loop below:

            for (int i = 0; i < NUMBER_OF_WAITING_THREADS; i++) {
                expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS + i + 1;
                expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS - i - 1;
                lockCheck.notify(); // notify waiting threads one by one
                // now the notified WaitingTask has to be blocked on the lockCheck re-enter

                // entry count: 1
                // count of threads waiting to enter:       NUMBER_OF_ENTERING_THREADS
                // count of threads waiting to re-enter:    i + 1
                // count of threads waiting to be notified: NUMBER_OF_WAITING_THREADS - i - 1
                check(lockCheck, expOwnerThread(), expEntryCount(),
                      expEnteringCount,
                      expWaitingCount);
            }

The comment fixed as you suggest does not look useful anymore as the tested pattern is lost:

                // entry count: expOwnerThread()
                // count of threads waiting to enter:       expEnteringCount
                // count of threads waiting to re-enter:   expEntryCount()
                // count of threads waiting to be notified: expWaitingCount
                check(lockCheck, expOwnerThread(), expEntryCount(),
                      expEnteringCount,
                      expWaitingCount);
            }


I understand your concern but your suggestion is not that good.
We could remove these comments but the tested pattern will be thrown away with the comments.
Would it help if we add clarifications that the comments are correct for platform threads only?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1589041287

From ayang at openjdk.org  Fri May  3 12:49:03 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 May 2024 12:49:03 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v2]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  s1-do-collect

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

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=01
  Stats: 558 lines in 15 files changed: 126 ins; 348 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From sgehwolf at openjdk.org  Fri May  3 15:57:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 15:57:53 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
 <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@github.com>
Message-ID: <NU1gZuqhkiITVFFSKPN_X6CqWOQ6Q2yC7n2QZatjYjE=.7b477cbb-7087-4b3a-83bd-7c9e45298d18@github.com>

On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
>> 
>>> 349:     //
>>> 350:     // We collect the read only mount option in the cgroup infos so as to have that
>>> 351:     // info ready when determining is_containerized().
>> 
>> Here, and in other places: a comment indicating the line format we scan would be appreciated, possibly with argument numbers. Saves the casual code reader from looking into proc man page. Even just pasting the example line for proc manpage would be fine (https://man7.org/linux/man-pages/man5/proc.5.html) (but with order adapted to your scanf call, they count major:minor as one)
>
> Trying to parse the `%s%*[^-]-`
> 
> So, %s parses the mount options, until we encounter whitespace. Then %*[^-]- parses everything that is not a dash, until we encounter the dash? Then we eat the dash? This is to skip the optionals?

Correct. Note that `%s %*[^-]` doesn't work for files without optionals. Since `%*[^-]` requires a non-empty match and the optionals are, well, optional :-) I've added more verbose comments to clarify this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589390841

From sgehwolf at openjdk.org  Fri May  3 15:57:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 15:57:57 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
Message-ID: <51Pz76bzLcZkgBLkoQeslRRTqztF2mIfSsvAZjo38uY=.7c1b4958-56b2-49c8-9311-74d83dfc355f@github.com>

On Tue, 16 Apr 2024 18:16:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - jcheck fixes
>>  - Fix tests
>>  - Implement Metrics.isContainerized()
>>  - Some clean-up
>>  - Drop cgroups testing on plain Linux
>>  - Implement fall-back logic for non-ro controller mounts
>>  - Make find_ro static and local to compilation unit
>>  - 8261242: [Linux] OSContainer::is_containerized() returns true
>
> src/hotspot/os/linux/osContainer_linux.cpp line 78:
> 
>> 76:   const char *reason;
>> 77:   bool any_mem_cpu_limit_present = false;
>> 78:   bool ctrl_ro = cgroup_subsystem->is_containerized();
> 
> nit: naming? what does ctrl mean in this case? Maybe use "cgroup_is_containerized"?

`ctrl` was short for `controller`. I've changed the naming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589391426

From sgehwolf at openjdk.org  Fri May  3 16:00:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:00:54 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
Message-ID: <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@github.com>

On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why return here?

Because it's not useful to see containerized settings (other than the cg version in use) after this patch. The JVM won't use them (uses the physical settings instead). Why would you want to show the settings?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589396352

From sgehwolf at openjdk.org  Fri May  3 16:05:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:05:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v3]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <fjbRaZcJI5fetXc1CnGpQK18sjgkhp2Ir6UWNhzYvLs=.f7bd259d-dc6a-46ea-bb58-e062d18eeedb@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf 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 12 additional commits since the last revision:

 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - Drop cgroups testing on plain Linux
 - Implement fall-back logic for non-ro controller mounts
 - ... and 2 more: https://git.openjdk.org/jdk/compare/06fa7bd3...434430ca

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18201/files
  - new: https://git.openjdk.org/jdk/pull/18201/files/0df26ebd..434430ca

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

  Stats: 82529 lines in 2377 files changed: 37138 ins; 34932 del; 10459 mod
  Patch: https://git.openjdk.org/jdk/pull/18201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18201/head:pull/18201

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

From sgehwolf at openjdk.org  Fri May  3 16:05:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:05:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
 <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>
Message-ID: <XYvopW80AoPjjrZi3EjaUNMoXGcxDI_FgRcJF8u0Z1w=.2d8a6999-99aa-4465-b425-52f1ec5ee042@github.com>

On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Anyway in this patch one could unify naming across variables/parameters, the same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.

I've tried to unify the naming a bit. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2093300919

From sgehwolf at openjdk.org  Fri May  3 16:12:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:12:53 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
 <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@github.com>
Message-ID: <h0zT2JxPmx_4Drmpb81rMkZdev3oKkcOTGVPku1rxgg=.f9451674-46fe-45e0-9b67-8c460dc7656f@github.com>

On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:
>> 
>>> 373:         if (!c.isContainerized()) {
>>> 374:             ostream.println(INDENT + "System not containerized.");
>>> 375:             return;
>> 
>> Why return here? Would this not cut the output short in the non-containerized case?
>> 
>> And if this not intended, the not-containerized-`-XshowSettings:system` test below should test and catch this (e.g. scan for CPU set)
>
>> Why return here?
> 
> Because it's not useful to see containerized settings (other than the cg version in use) after this patch. The JVM won't use them (uses the physical settings instead). Why would you want to show the settings?

To clarify. `showSettings:system` output on a host system:


Operating System Metrics:
    Provider: cgroupv1
    System not containerized.
openjdk 23-internal 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)


... and in a container (with memory limit 500m):


Operating System Metrics:
    Provider: cgroupv1
    Effective CPU Count: 12
    CPU Period: 100000us
    CPU Quota: -1
    CPU Shares: -1
    List of Processors, 12 total: 
    0 1 2 3 4 5 6 7 8 9 10 11 
    List of Effective Processors, 12 total: 
    0 1 2 3 4 5 6 7 8 9 10 11 
    List of Memory Nodes, 1 total: 
    0 
    List of Available Memory Nodes, 1 total: 
    0 
    Memory Limit: 500.00M
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: 500.00M
    Maximum Processes Limit: 2048

openjdk 23-internal 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589407238

From duke at openjdk.org  Fri May  3 16:45:52 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Fri, 3 May 2024 16:45:52 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <Jk9ZRtKNjObL0Kbv_HLDce8MmRqsLAOjCivT8K8jFEs=.a41d5f62-5b6c-4f72-b5d9-81ac72014d23@github.com>

On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Thanks for the patch @larry-cable, much appreciated! I really like this idea.

I tried it out a bit locally. These cases seem to work:
- attaching to a process running on the same host (PID and mount namespace the same)
- attaching as root from the host to a JVM inside a container
- attaching from a sidecar container to a JVM in another container

Unfortunately, attaching to a JVM process running as the same user in the same PID and mount namespace but one that has elevated privileges no longer works (the case that JDK-8226919 fixed). That case ends up failing like this with the patch:


slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 1751545 VM.version
1751545:
java.io.IOException: Unable to access root directory /proc/1751545/root of target process 1751545
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


I _think_ it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.


slovdahl at ubuntu2204:/proc/1751545/ns$ ls -lh
ls: cannot read symbolic link 'net': Permission denied
ls: cannot read symbolic link 'uts': Permission denied
ls: cannot read symbolic link 'ipc': Permission denied
ls: cannot read symbolic link 'pid': Permission denied
ls: cannot read symbolic link 'pid_for_children': Permission denied
ls: cannot read symbolic link 'user': Permission denied
ls: cannot read symbolic link 'mnt': Permission denied
ls: cannot read symbolic link 'cgroup': Permission denied
ls: cannot read symbolic link 'time': Permission denied
ls: cannot read symbolic link 'time_for_children': Permission denied
total 0
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts
slovdahl at ubuntu2204:/proc/1751545/ns$ sudo ls -lh
total 0
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt -> 'mnt:[4026533862]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net -> 'net:[4026531840]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children -> 'pid:[4026531836]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time -> 'time:[4026531834]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user -> 'user:[4026531837]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts -> 'uts:[4026531838]'


FWIW, my IntelliJ also highlighted the fact that the suggested patch contains unreachable code. The `else throw new IOException(String.format("target process:%d and this do not share common mount namespace for: %s attach failed", pid, tmpdir));` path can never be taken, because either the `if` statement evaluates to `true`, or the `else if`.

I'm not sure if we can do any better than always falling back to `/tmp`? But if anyone has suggestions, I'm certainly happy to try it out.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2093378574

From larry.cable at oracle.com  Fri May  3 17:02:02 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Fri, 3 May 2024 10:02:02 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container)
In-Reply-To: <Jk9ZRtKNjObL0Kbv_HLDce8MmRqsLAOjCivT8K8jFEs=.a41d5f62-5b6c-4f72-b5d9-81ac72014d23@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <Jk9ZRtKNjObL0Kbv_HLDce8MmRqsLAOjCivT8K8jFEs=.a41d5f62-5b6c-4f72-b5d9-81ac72014d23@github.com>
Message-ID: <65740845-84d6-4c6d-84d0-01f92e38efaf@oracle.com>

I'll ponder ... have a good weekend!

regardless I think the added check for mnt ns comparison "adds value" by 
expressing the constraints explicitly vs comparing pid & ns pid

Rgds

- Larry


On 5/3/24 9:45 AM, Sebastian L?vdahl wrote:
> On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:
>
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
> Thanks for the patch @larry-cable, much appreciated! I really like this idea.
>
> I tried it out a bit locally. These cases seem to work:
> - attaching to a process running on the same host (PID and mount namespace the same)
> - attaching as root from the host to a JVM inside a container
> - attaching from a sidecar container to a JVM in another container
>
> Unfortunately, attaching to a JVM process running as the same user in the same PID and mount namespace but one that has elevated privileges no longer works (the case that JDK-8226919 fixed). That case ends up failing like this with the patch:
>
>
> slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 1751545 VM.version
> 1751545:
> java.io.IOException: Unable to access root directory /proc/1751545/root of target process 1751545
> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284)
> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229)
> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86)
> 	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
> 	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
> 	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
> 	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>
>
> I _think_ it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.
>
>
> slovdahl at ubuntu2204:/proc/1751545/ns$ ls -lh
> ls: cannot read symbolic link 'net': Permission denied
> ls: cannot read symbolic link 'uts': Permission denied
> ls: cannot read symbolic link 'ipc': Permission denied
> ls: cannot read symbolic link 'pid': Permission denied
> ls: cannot read symbolic link 'pid_for_children': Permission denied
> ls: cannot read symbolic link 'user': Permission denied
> ls: cannot read symbolic link 'mnt': Permission denied
> ls: cannot read symbolic link 'cgroup': Permission denied
> ls: cannot read symbolic link 'time': Permission denied
> ls: cannot read symbolic link 'time_for_children': Permission denied
> total 0
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts
> slovdahl at ubuntu2204:/proc/1751545/ns$ sudo ls -lh
> total 0
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup -> 'cgroup:[4026531835]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc -> 'ipc:[4026531839]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt -> 'mnt:[4026533862]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net -> 'net:[4026531840]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid -> 'pid:[4026531836]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children -> 'pid:[4026531836]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time -> 'time:[4026531834]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children -> 'time:[4026531834]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user -> 'user:[4026531837]'
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts -> 'uts:[4026531838]'
>
>
> FWIW, my IntelliJ also highlighted the fact that the suggested patch contains unreachable code. The `else throw new IOException(String.format("target process:%d and this do not share common mount namespace for: %s attach failed", pid, tmpdir));` path can never be taken, because either the `if` statement evaluates to `true`, or the `else if`.
>
> I'm not sure if we can do any better than always falling back to `/tmp`? But if anyone has suggestions, I'm certainly happy to try it out.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2093378574


From duke at openjdk.org  Fri May  3 17:43:52 2024
From: duke at openjdk.org (jdoylei)
Date: Fri, 3 May 2024 17:43:52 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com>

On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

> I think it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.

@slovdahl - In that test case (target JVM process has more privileges), where is the attach file created?  Does jcmd end up writing it to `/tmp`?  Or does `/proc/<pid>/cwd` work?  Just curious whether the elevated-privileges scenario affects the attach file and socket file locations equally.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2093481534

From cjplummer at openjdk.org  Fri May  3 18:33:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 May 2024 18:33:53 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <_OZZbnPJvcnrwvlHdh9i-_kEBHdK3QEo_qGfG_nE3XE=.536f045e-65e6-4a37-a22a-080476bf9a21@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

What "debugging option" are you referring to.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2093550055

From alanb at openjdk.org  Fri May  3 18:39:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 May 2024 18:39:51 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <_OZZbnPJvcnrwvlHdh9i-_kEBHdK3QEo_qGfG_nE3XE=.536f045e-65e6-4a37-a22a-080476bf9a21@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
 <_OZZbnPJvcnrwvlHdh9i-_kEBHdK3QEo_qGfG_nE3XE=.536f045e-65e6-4a37-a22a-080476bf9a21@github.com>
Message-ID: <dC89jLqRa0mAZ-7BqNuYl6U5T2GgvEx29W90p5yB6ZM=.e1f07ba9-fcd4-40f3-970a-b9f7a7a00521@github.com>

On Fri, 3 May 2024 18:31:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> What "debugging option" are you referring to.

`-Djdk.tracePinnedThreads=full`. When this system property is set then it means the onPinned callback is running the printing code. This is happen in a transition when running with JVMTI enabled. It dates from early development in the loom repo and was a mistake to bring it into the main line.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2093556941

From cjplummer at openjdk.org  Fri May  3 18:58:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 May 2024 18:58:51 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <gJIhU7O-wjD4JvfoA4M1yK0nkhxmLMAhL748Wftd4qo=.b658e18d-ebc9-42e5-8632-fa61484c5182@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19054#pullrequestreview-2038829389

From sspitsyn at openjdk.org  Fri May  3 20:19:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 May 2024 20:19:52 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <hOOLnK7TrHHQNy0gz4HoKA7H4OTPdGvuC_Ff0f_9RHE=.b385e8aa-cc3a-45b0-a56a-e8715cb0e582@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2093703364

From gli at openjdk.org  Sat May  4 03:14:06 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 4 May 2024 03:14:06 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v2]
In-Reply-To: <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com>
Message-ID: <SDv-LTMpUzAPEy04UTolDh7h8poT-_CMrl8v1OR8UU0=.033e3a2d-90e0-4bd4-b962-d9d7a3b52d08@github.com>

On Fri, 3 May 2024 12:49:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
>> 
>> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   s1-do-collect

Nice refactor.

src/hotspot/share/gc/serial/serialHeap.cpp line 442:

> 440: }
> 441: 
> 442: bool SerialHeap::do_young_gc(DefNewGeneration* young_gen, bool clear_soft_refs) {

The parameter `DefNewGeneration* young_gen` is not necessary. We can use the field `SerialHeap::_young_gen` directly.

src/hotspot/share/gc/serial/serialHeap.cpp line 461:

> 459:   if (should_verify && VerifyBeforeGC) {
> 460:     prepare_for_verify();
> 461:     Universe::verify("Before GC");

May the prefix of the verification log be better to specify the minor or full GC? Such as `Before Minor GC` here.

src/hotspot/share/gc/serial/serialHeap.cpp line 463:

> 461:     Universe::verify("Before GC");
> 462:   }
> 463:   gc_prologue(false);

The parameter `full` of the method `SerialHeap::gc_prologue` doesn't been used. Seems a leftover of [JDK-8323993](https://bugs.openjdk.org/browse/JDK-8323993).

src/hotspot/share/gc/serial/serialHeap.cpp line 468:

> 466:   gen->stat_record()->accumulated_time.stop();
> 467: 
> 468:   update_gc_stats(gen, full);

The method `update_gc_stats` is only used by young-gen to sample the promoted size. It is good to rename and simplify the related code. I filed https://bugs.openjdk.org/browse/JDK-8331684 to follow up.

src/hotspot/share/gc/serial/serialHeap.cpp line 660:

> 658:   }
> 659:   do_full_collection_no_gc_locker(clear_soft_refs);
> 660: }

Please note the difference between the previous `SerialHeap::do_collection` and `SerialHeap::collect_at_safepoint_no_gc_locker` here. The previous `SerialHeap::do_collection` may invoke full GC according to the method `SerialHeap::should_do_full_collection` even the young GC succeeded. But `SerialHeap::collect_at_safepoint_no_gc_locker` only invokes full GC when the young GC failed (because of failed promotion). Such change makes the `SerialHeap::should_do_full_collection` has no user. If the behaviour of the `SerialHeap::collect_at_safepoint_no_gc_locker` is your intention, I think it is good to remove `SerialHeap::should_do_full_collection`.

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

Changes requested by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19056#pullrequestreview-2039185857
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1589844934
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1589860506
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1589859847
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1589857649
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1589863014

From duke at openjdk.org  Sat May  4 03:32:19 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 4 May 2024 03:32:19 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v7]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <-j4lM2hWQmtYu9jJ9WQ8l_dhoU4newkCfxq9-66_Gx4=.e6633ac1-2ab1-4d45-b051-ef589e1412bd@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - rename
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
 - review
 - Merge branch 'master' into JDK-8330694
 - fix indentation
 - also tidy up
 - tidy up
 - rename

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

Changes: https://git.openjdk.org/jdk/pull/18871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18871&range=06
  Stats: 999 lines in 124 files changed: 1 ins; 4 del; 994 mod
  Patch: https://git.openjdk.org/jdk/pull/18871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18871/head:pull/18871

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

From duke at openjdk.org  Sat May  4 03:42:17 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 4 May 2024 03:42:17 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v8]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <D6uHWPoJoY6OyXXFLA7v3yvJFyjhGLkVAn2SpOBosGo=.e743b83f-d2f0-49b4-8764-97b15e3a495c@github.com>

> follow up 8267941

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/4d175e27..80eeb443

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

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

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

From duke at openjdk.org  Sat May  4 03:45:31 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 4 May 2024 03:45:31 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v9]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <7Aud9EX-Q09Bx3MmZjM182gBp9sDmbvIt7rSmtBa1FM=.cc43a81c-7431-484d-9eae-295da93c9a52@github.com>

> follow up 8267941

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/80eeb443..b007eb01

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

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

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

From sspitsyn at openjdk.org  Sat May  4 10:06:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 4 May 2024 10:06:54 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of
 othervm
In-Reply-To: <jKqiQ2JTRc5nhMKuzBPlkCv3yaSfUVEbwpy69cZ_GOU=.cda8ed5a-b094-445c-9133-abcedaa5d594@github.com>
References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
 <jKqiQ2JTRc5nhMKuzBPlkCv3yaSfUVEbwpy69cZ_GOU=.cda8ed5a-b094-445c-9133-abcedaa5d594@github.com>
Message-ID: <qOaAPZxaqosfU_plx3TvCkooDWVL1r5zIpW8WBBW-Fo=.a347a81e-1c51-42e8-94ec-9e9371b9eb35@github.com>

On Mon, 22 Apr 2024 11:21:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> The jdwp tests use debugger and debugee. There is no goal to execute debugger part with all VM flags, they are needed to be used with debugee VM only.
>> The change is all tests is to don't use System.exit() and use 'driver' instead of othervm.
>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
>> is updated to correctly set classpath for debugee
>
> test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001.java line 93:
> 
>> 91:      */
>> 92:     public static void main (String argv[]) {
>> 93:         int result = run(argv,System.out);
> 
> Suggestion:
> 
>         int result = run(argv, System.out);

Yes, this missing space is all over this fix. Need to fix this formatting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1589950014

From sspitsyn at openjdk.org  Sat May  4 10:09:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 4 May 2024 10:09:51 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of
 othervm
In-Reply-To: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
Message-ID: <wGAtAh2SWtoNHsRphkjh9pRspJ8kaYr9ULr3wmTndmo=.5eac2141-71e6-4411-a953-44769d038ee0@github.com>

On Wed, 17 Apr 2024 20:19:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The jdwp tests use debugger and debugee. There is no goal to execute debugger part with all VM flags, they are needed to be used with debugee VM only.
> The change is all tests is to don't use System.exit() and use 'driver' instead of othervm.
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
> is updated to correctly set classpath for debugee

This looks okay in general.
There is a missing space in half of files in method `run()` parameters noticed by Andrei.
Also, Chris had some concerns about converting to the `driver` mode.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18826#pullrequestreview-2039316239

From sspitsyn at openjdk.org  Sat May  4 10:21:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 4 May 2024 10:21:52 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v4]
In-Reply-To: <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
Message-ID: <BGLHU5_jKTlJP9-nVtMazm6YFyixDwUXGBIoC9ByVPQ=.902a2402-3fd7-4596-81df-2a20557f967c@github.com>

On Fri, 3 May 2024 01:54:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update
>  - Revert "renamed current_thread to current"
>    
>    This reverts commit d5d614bcf0861466acd695296e974d2253f84c9f.
>  - Revert "renamed current_thread tp current"
>    
>    This reverts commit 4602632221044aa754a1bc8d11e7a3e9a0092590.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18986#pullrequestreview-2039319268

From sspitsyn at openjdk.org  Sat May  4 10:24:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 4 May 2024 10:24:51 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64
In-Reply-To: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
Message-ID: <OBwcnZm_YZN3h_YO8sDeP4FhH-h8ZEX4E7SUrVldz88=.78ad332a-868f-486e-9041-1d264ad027c5@github.com>

On Wed, 1 May 2024 14:14:22 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
> 
>   Only change the ProblemList, no risk.

Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19033#pullrequestreview-2039319669

From larry.cable at oracle.com  Sat May  4 21:06:35 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Sat, 4 May 2024 14:06:35 -0700
Subject: [External] : Re: [openjdk/jdk] 8327114: Attach in Linux may have
 wrong behaviour when pid == ns_pid (Kubernetes debug container) (PR
 #19055)
In-Reply-To: <openjdk/jdk/pull/19055/c2093378574@github.com>
References: <openjdk/jdk/pull/19055@github.com>
 <openjdk/jdk/pull/19055/c2093378574@github.com>
Message-ID: <08bd0044-82bf-4cf4-a909-e5f1e9ef6506@oracle.com>

so I think to summarize the logic we require:

1) if we can determine that the attacher and attachee occupy the same 
mnt ns (/proc/<attacher>/ns/mnt == /proc/<attachee>/ns/mnt), return "/tmp"
2) if they are not in the same mnt ns:
 ??? - test the /proc/<attachee>/root/tmp path for readability, if it 
is, return that
 ??? - if it is not readable (its either secured with elevated privs and 
it exists) return "/tmp" which may still fail because they are in fact 
not in the same mnt ns

what about /proc/<attachee>/cwd?

- Larry


On 5/3/24 9:43 AM, Sebastian L?vdahl wrote:
>
> Thanks for the patch @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5xDccS1BA$>, 
> much appreciated! I really like this idea.
>
> I tried it out a bit locally. These cases seem to work:
>
>   * attaching to a process running on the same host (PID and mount
>     namespace the same)
>   * attaching as root from the host to a JVM inside a container
>   * attaching from a sidecar container to a JVM in another container
>
> Unfortunately, attaching to a JVM process running as the same user in 
> the same PID and mount namespace but one that has elevated privileges 
> no longer works (the case that JDK-8226919 fixed). That case ends up 
> failing like this with the patch:
>
> |slovdahl at ubuntu2204:~/reproducer$ 
> /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 
> 1751545 VM.version 1751545: java.io.IOException: Unable to access root 
> directory /proc/1751545/root of target process 1751545 at 
> jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284) 
> at 
> jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229) 
> at 
> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86) 
> at 
> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) 
> at 
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) 
> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) at 
> jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) |
>
> I /think/ it boils down to the same reason as why the fix for 
> JDK-8226919 was needed in the first place - a non-root user cannot 
> read the symlinks in |/proc/<pid>/ns| for a process running with more 
> privileges even though it's run by the same non-root user.
>
> |slovdahl at ubuntu2204:/proc/1751545/ns$ ls -lh ls: cannot read symbolic 
> link 'net': Permission denied ls: cannot read symbolic link 'uts': 
> Permission denied ls: cannot read symbolic link 'ipc': Permission 
> denied ls: cannot read symbolic link 'pid': Permission denied ls: 
> cannot read symbolic link 'pid_for_children': Permission denied ls: 
> cannot read symbolic link 'user': Permission denied ls: cannot read 
> symbolic link 'mnt': Permission denied ls: cannot read symbolic link 
> 'cgroup': Permission denied ls: cannot read symbolic link 'time': 
> Permission denied ls: cannot read symbolic link 'time_for_children': 
> Permission denied total 0 lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
> cgroup lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 ipc lrwxrwxrwx 1 
> slovdahl slovdahl 0 maj 3 19:27 mnt lrwxrwxrwx 1 slovdahl slovdahl 0 
> maj 3 19:28 net lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 pid 
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 pid_for_children 
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 time lrwxrwxrwx 1 
> slovdahl slovdahl 0 maj 3 19:28 time_for_children lrwxrwxrwx 1 
> slovdahl slovdahl 0 maj 3 19:28 user lrwxrwxrwx 1 slovdahl slovdahl 0 
> maj 3 19:28 uts slovdahl at ubuntu2204:/proc/1751545/ns$ sudo ls -lh 
> total 0 lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 cgroup -> 
> 'cgroup:[4026531835]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 ipc 
> -> 'ipc:[4026531839]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:27 mnt 
> -> 'mnt:[4026533862]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 net 
> -> 'net:[4026531840]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 pid 
> -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
> pid_for_children -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl slovdahl 
> 0 maj 3 19:28 time -> 'time:[4026531834]' lrwxrwxrwx 1 slovdahl 
> slovdahl 0 maj 3 19:28 time_for_children -> 'time:[4026531834]' 
> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 user -> 
> 'user:[4026531837]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 uts 
> -> 'uts:[4026531838]' |
>
> FWIW, my IntelliJ also highlighted the fact that the suggested patch 
> contains unreachable code. The |else throw new 
> IOException(String.format("target process:%d and this do not share 
> common mount namespace for: %s attach failed", pid, tmpdir));| path 
> can never be taken, because either the |if| statement evaluates to 
> |true|, or the |else if|.
>
> I'm not sure if we can do any better than always falling back to 
> |/tmp|? But if anyone has suggestions, I'm certainly happy to try it out.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2093378574__;Iw!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wAeEv03g$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UD2AU4WJYYSI7427LZAO5CTAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGM3TQNJXGQ__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wuDyNaeA$>.
> You are receiving this because you were mentioned.Message ID: 
> <openjdk/jdk/pull/19055/c2093378574 at github.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240504/d22f7c93/attachment-0001.htm>

From syan at openjdk.org  Sun May  5 11:50:51 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 5 May 2024 11:50:51 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64
In-Reply-To: <OBwcnZm_YZN3h_YO8sDeP4FhH-h8ZEX4E7SUrVldz88=.78ad332a-868f-486e-9041-1d264ad027c5@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <OBwcnZm_YZN3h_YO8sDeP4FhH-h8ZEX4E7SUrVldz88=.78ad332a-868f-486e-9041-1d264ad027c5@github.com>
Message-ID: <cnntD0NMj8pigA9DcHaBgtAXR0oe7W9YzGrNmax2tMA=.82a0f81c-ff4f-495e-bbfe-1a80ccf155b3@github.com>

On Sat, 4 May 2024 10:22:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Looks okay to me.

@sspitsyn Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2094774327

From lmesnik at openjdk.org  Sun May  5 18:07:47 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 5 May 2024 18:07:47 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of
 othervm [v2]
In-Reply-To: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
Message-ID: <X7dKs8cG-NIvnLfsDG54mTLJ_3riChSNyQQgEmn7tOs=.f00180c8-3179-4330-9fb8-44dd170fe776@github.com>

> The jdwp tests use debugger and debugee. There is no goal to execute debugger part with all VM flags, they are needed to be used with debugee VM only.
> The change is all tests is to don't use System.exit() and use 'driver' instead of othervm.
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
> is updated to correctly set classpath for debugee

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

  identation updated.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18826/files
  - new: https://git.openjdk.org/jdk/pull/18826/files/122446b6..efd5a7db

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

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

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

From lmesnik at openjdk.org  Sun May  5 18:07:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 5 May 2024 18:07:48 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of
 othervm [v2]
In-Reply-To: <jKqiQ2JTRc5nhMKuzBPlkCv3yaSfUVEbwpy69cZ_GOU=.cda8ed5a-b094-445c-9133-abcedaa5d594@github.com>
References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
 <jKqiQ2JTRc5nhMKuzBPlkCv3yaSfUVEbwpy69cZ_GOU=.cda8ed5a-b094-445c-9133-abcedaa5d594@github.com>
Message-ID: <tdTqCnY9gMNB5zrpfw88VfPDZYxdCFWmLlGxhS6I1qY=.8a660476-c75c-4242-b1a6-370942f64a3d@github.com>

On Mon, 22 Apr 2024 11:21:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   identation updated.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001.java line 101:
> 
>> 99:      */
>> 100:     public static void main (String argv[]) {
>> 101:         int result = run(argv,System.out);
> 
> Suggestion:
> 
>         int result = run(argv, System.out);

Thanks, I update the indentation in all places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1590376511

From jpai at openjdk.org  Mon May  6 00:38:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 May 2024 00:38:55 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v3]
In-Reply-To: <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
Message-ID: <YSGMdKwQJlmSPhvOdIEqwb1_v7cj2VuhmYkiE2mZwpo=.5e6f8372-999b-4135-8cc5-6fd84bf803c8@github.com>

On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review - DaemonThreadTest.java, no need for checking if thread is virtual

I'm looking for an additional second review of this one, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/19016#issuecomment-2095021638

From ayang at openjdk.org  Mon May  6 09:28:13 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 May 2024 09:28:13 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v2]
In-Reply-To: <SDv-LTMpUzAPEy04UTolDh7h8poT-_CMrl8v1OR8UU0=.033e3a2d-90e0-4bd4-b962-d9d7a3b52d08@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com>
 <SDv-LTMpUzAPEy04UTolDh7h8poT-_CMrl8v1OR8UU0=.033e3a2d-90e0-4bd4-b962-d9d7a3b52d08@github.com>
Message-ID: <-Vn0Bjjlrq0l5PlHprZIFIETB5YUhw9MQLKh9cKO6LA=.262cec6e-865d-4d55-be6c-d60a08934d08@github.com>

On Sat, 4 May 2024 02:39:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   s1-do-collect
>
> src/hotspot/share/gc/serial/serialHeap.cpp line 461:
> 
>> 459:   if (should_verify && VerifyBeforeGC) {
>> 460:     prepare_for_verify();
>> 461:     Universe::verify("Before GC");
> 
> May the prefix of the verification log be better to specify the minor or full GC? Such as `Before Minor GC` here.

Other `Universe::verify("` seems to not distinguish minor/major.

> src/hotspot/share/gc/serial/serialHeap.cpp line 463:
> 
>> 461:     Universe::verify("Before GC");
>> 462:   }
>> 463:   gc_prologue(false);
> 
> The parameter `full` of the method `SerialHeap::gc_prologue` doesn't been used. Seems a leftover of [JDK-8323993](https://bugs.openjdk.org/browse/JDK-8323993).

True; can probably fixed in a followup cleanup.

> src/hotspot/share/gc/serial/serialHeap.cpp line 660:
> 
>> 658:   }
>> 659:   do_full_collection_no_gc_locker(clear_soft_refs);
>> 660: }
> 
> Please note the difference between the previous `SerialHeap::do_collection` and `SerialHeap::collect_at_safepoint_no_gc_locker` here. The previous `SerialHeap::do_collection` may invoke full GC according to the method `SerialHeap::should_do_full_collection` even the young GC succeeded. But `SerialHeap::collect_at_safepoint_no_gc_locker` only invokes full GC when the young GC failed (because of failed promotion). Such change makes the `SerialHeap::should_do_full_collection` has no user. If the behaviour of the `SerialHeap::collect_at_safepoint_no_gc_locker` is your intention, I think it is good to remove `SerialHeap::should_do_full_collection`.

Removed `should_do_full_collection`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1590740631
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1590740947
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1590741518

From ayang at openjdk.org  Mon May  6 09:28:13 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 May 2024 09:28:13 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v3]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <f17h9O7LccCzCo-TyiuNXZ0dHvWZqHp4zSVD-lcDvh0=.af10e0d8-9370-432b-ac0e-1926491386d0@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

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

 - review
 - Merge branch 'master' into s1-do-collect
 - s1-do-collect

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19056/files
  - new: https://git.openjdk.org/jdk/pull/19056/files/7375bfbf..d8d5a13e

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

  Stats: 2776 lines in 84 files changed: 2057 ins; 489 del; 230 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From shade at openjdk.org  Mon May  6 11:21:56 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 May 2024 11:21:56 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <6hpNRaO10dRNfshEfX3RHSxY5lcxrLeU1wH7zUDqTlA=.40086db0-2a55-4735-8a78-13f154e9155d@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all`

Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/19064#issuecomment-2095775823

From shade at openjdk.org  Mon May  6 11:21:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 May 2024 11:21:57 GMT
Subject: RFR: 8331573: Rename CollectedHeap::is_gc_active to be explicitly
 about STW GCs
In-Reply-To: <8rTp30vldMrfGYMh6uP-tirE9bjNGTBePOSztx95MD4=.8f9cdead-0301-42c4-acad-a2bfc26b4702@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
 <fr25GpyrOEBZlCs0JyygHSuvMEQ9rSoMmGa-M7vxUxc=.2f9a3033-801d-48ac-ae44-d1115ae51f47@github.com>
 <uhO3PJxmP13Eowq9xjkg_rg42uQhEet8jvvRDyGYnHo=.6c013ce1-aaeb-4f8d-b480-a4eb5fe39af9@github.com>
 <8rTp30vldMrfGYMh6uP-tirE9bjNGTBePOSztx95MD4=.8f9cdead-0301-42c4-acad-a2bfc26b4702@github.com>
Message-ID: <a4-eSmGfS8T4pXNbZ2aeJOXQ_b3PmlRw9uRcMh_d1vo=.874668eb-e7a0-4847-86ec-5e2b03a4a591@github.com>

On Thu, 2 May 2024 17:26:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ah, hm. Indeed! Separate PR? There is some light cleanup in G1 that can be associated with it. This PR would keep with just a mechanical rename.
>
> Sounds like a good idea.

Filed: https://bugs.openjdk.org/browse/JDK-8331719 -- I'll give it out to some of our folks as a starter task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19064#discussion_r1590876454

From shade at openjdk.org  Mon May  6 11:21:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 May 2024 11:21:57 GMT
Subject: Integrated: 8331573: Rename CollectedHeap::is_gc_active to be
 explicitly about STW GCs
In-Reply-To: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
References: <ZXkiqLdTHyB_wVe2UFk9MyP8cZwgHl1XXFfGNv6X9Qo=.793fd4cd-f34d-4620-8b89-b43423e00b27@github.com>
Message-ID: <itqD6KuTJwl40Jq1Jo-M0I1bizP9HPDMb9e3eVj1I4g=.800cbaa3-f20e-45aa-9b8a-1d1968e1ed83@github.com>

On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC phase is running, while it actually only covers the STW GCs. It would be good to rename it for clarity. The freed-up name, `is_gc_active` could then be repurposed to track any (concurrent or STW) GC phase running. That would be useful to resolve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572).
> 
> Doing this rename separately guarantees we have caught and renamed all current uses.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 1eec30a6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1eec30a6c03b7f4028405dc9bdb4d2a663b3987d
Stats:     64 lines in 27 files changed: 0 ins; 2 del; 62 mod

8331573: Rename CollectedHeap::is_gc_active to be explicitly about STW GCs

Reviewed-by: stefank, zgu, tschatzl, gli

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

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

From ayang at openjdk.org  Mon May  6 11:39:16 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 May 2024 11:39:16 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v4]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <Oh_usRr4QlSNLUPXlKaYBOC9zPvRGBr1Pvo_-Al78jk=.7a0eb8c4-beaa-4c57-9439-e83ad0a7f495@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - merge
 - review
 - Merge branch 'master' into s1-do-collect
 - s1-do-collect

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

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=03
  Stats: 566 lines in 15 files changed: 125 ins; 356 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From gli at openjdk.org  Mon May  6 11:58:53 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 6 May 2024 11:58:53 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v2]
In-Reply-To: <-Vn0Bjjlrq0l5PlHprZIFIETB5YUhw9MQLKh9cKO6LA=.262cec6e-865d-4d55-be6c-d60a08934d08@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com>
 <SDv-LTMpUzAPEy04UTolDh7h8poT-_CMrl8v1OR8UU0=.033e3a2d-90e0-4bd4-b962-d9d7a3b52d08@github.com>
 <-Vn0Bjjlrq0l5PlHprZIFIETB5YUhw9MQLKh9cKO6LA=.262cec6e-865d-4d55-be6c-d60a08934d08@github.com>
Message-ID: <AULt9PEi6_jNNUh4FbjGZFEGF8ckYnDaVroYFl8YGjQ=.6c371fc5-00dc-4299-8c05-e395d1f764e1@github.com>

On Mon, 6 May 2024 09:12:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialHeap.cpp line 461:
>> 
>>> 459:   if (should_verify && VerifyBeforeGC) {
>>> 460:     prepare_for_verify();
>>> 461:     Universe::verify("Before GC");
>> 
>> May the prefix of the verification log be better to specify the minor or full GC? Such as `Before Minor GC` here.
>
> Other `Universe::verify("` seems to not distinguish minor/major.

OK. If someone want to change all of them in the future, she/he can file another ticket to follow up.

>> src/hotspot/share/gc/serial/serialHeap.cpp line 463:
>> 
>>> 461:     Universe::verify("Before GC");
>>> 462:   }
>>> 463:   gc_prologue(false);
>> 
>> The parameter `full` of the method `SerialHeap::gc_prologue` doesn't been used. Seems a leftover of [JDK-8323993](https://bugs.openjdk.org/browse/JDK-8323993).
>
> True; can probably fixed in a followup cleanup.

Filed https://bugs.openjdk.org/browse/JDK-8331723 to follow up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1590915891
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1590915740

From sebastian.lovdahl at hibox.tv  Mon May  6 16:16:37 2024
From: sebastian.lovdahl at hibox.tv (=?UTF-8?Q?Sebastian_L=C3=B6vdahl?=)
Date: Mon, 6 May 2024 19:16:37 +0300
Subject: [External] : Re: [openjdk/jdk] 8327114: Attach in Linux may have
 wrong behaviour when pid == ns_pid (Kubernetes debug container) (PR
 #19055)
In-Reply-To: <08bd0044-82bf-4cf4-a909-e5f1e9ef6506@oracle.com>
References: <openjdk/jdk/pull/19055@github.com>
 <openjdk/jdk/pull/19055/c2093378574@github.com>
 <08bd0044-82bf-4cf4-a909-e5f1e9ef6506@oracle.com>
Message-ID: <4f7b3865-951c-472d-8b89-3abc7c0d0350@hibox.tv>

Yep, that sounds reasonable. I'll try to work something out along these 
lines, thanks for the input!

Unfortunately, /proc/<attachee>/cwd is also restricted in the same way 
as /proc/<attachee>/root is.

/Sebastian

On 2024-05-05 00:06, Laurence Cable wrote:
> so I think to summarize the logic we require:
>
> 1) if we can determine that the attacher and attachee occupy the same 
> mnt ns (/proc/<attacher>/ns/mnt == /proc/<attachee>/ns/mnt), return "/tmp"
> 2) if they are not in the same mnt ns:
> ??? - test the /proc/<attachee>/root/tmp path for readability, if it 
> is, return that
> ??? - if it is not readable (its either secured with elevated privs 
> and it exists) return "/tmp" which may still fail because they are in 
> fact not in the same mnt ns
>
> what about /proc/<attachee>/cwd?
>
> - Larry
>
>
> On 5/3/24 9:43 AM, Sebastian L?vdahl wrote:
>>
>> Thanks for the patch @larry-cable 
>> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5xDccS1BA$>, 
>> much appreciated! I really like this idea.
>>
>> I tried it out a bit locally. These cases seem to work:
>>
>>   * attaching to a process running on the same host (PID and mount
>>     namespace the same)
>>   * attaching as root from the host to a JVM inside a container
>>   * attaching from a sidecar container to a JVM in another container
>>
>> Unfortunately, attaching to a JVM process running as the same user in 
>> the same PID and mount namespace but one that has elevated privileges 
>> no longer works (the case that JDK-8226919 fixed). That case ends up 
>> failing like this with the patch:
>>
>> |slovdahl at ubuntu2204:~/reproducer$ 
>> /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 
>> 1751545 VM.version 1751545: java.io.IOException: Unable to access 
>> root directory /proc/1751545/root of target process 1751545 at 
>> jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284) 
>> at 
>> jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229) 
>> at 
>> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86) 
>> at 
>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) 
>> at 
>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) 
>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) 
>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) |
>>
>> I /think/ it boils down to the same reason as why the fix for 
>> JDK-8226919 was needed in the first place - a non-root user cannot 
>> read the symlinks in |/proc/<pid>/ns| for a process running with more 
>> privileges even though it's run by the same non-root user.
>>
>> |slovdahl at ubuntu2204:/proc/1751545/ns$ ls -lh ls: cannot read 
>> symbolic link 'net': Permission denied ls: cannot read symbolic link 
>> 'uts': Permission denied ls: cannot read symbolic link 'ipc': 
>> Permission denied ls: cannot read symbolic link 'pid': Permission 
>> denied ls: cannot read symbolic link 'pid_for_children': Permission 
>> denied ls: cannot read symbolic link 'user': Permission denied ls: 
>> cannot read symbolic link 'mnt': Permission denied ls: cannot read 
>> symbolic link 'cgroup': Permission denied ls: cannot read symbolic 
>> link 'time': Permission denied ls: cannot read symbolic link 
>> 'time_for_children': Permission denied total 0 lrwxrwxrwx 1 slovdahl 
>> slovdahl 0 maj 3 19:28 cgroup lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>> 19:28 ipc lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:27 mnt lrwxrwxrwx 
>> 1 slovdahl slovdahl 0 maj 3 19:28 net lrwxrwxrwx 1 slovdahl slovdahl 
>> 0 maj 3 19:28 pid lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>> pid_for_children lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 time 
>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 time_for_children 
>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 user lrwxrwxrwx 1 
>> slovdahl slovdahl 0 maj 3 19:28 uts 
>> slovdahl at ubuntu2204:/proc/1751545/ns$ sudo ls -lh total 0 lrwxrwxrwx 
>> 1 slovdahl slovdahl 0 maj 3 19:28 cgroup -> 'cgroup:[4026531835]' 
>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 ipc -> 
>> 'ipc:[4026531839]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:27 mnt 
>> -> 'mnt:[4026533862]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>> net -> 'net:[4026531840]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>> 19:28 pid -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 
>> 3 19:28 pid_for_children -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl 
>> slovdahl 0 maj 3 19:28 time -> 'time:[4026531834]' lrwxrwxrwx 1 
>> slovdahl slovdahl 0 maj 3 19:28 time_for_children -> 
>> 'time:[4026531834]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 user 
>> -> 'user:[4026531837]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>> uts -> 'uts:[4026531838]' |
>>
>> FWIW, my IntelliJ also highlighted the fact that the suggested patch 
>> contains unreachable code. The |else throw new 
>> IOException(String.format("target process:%d and this do not share 
>> common mount namespace for: %s attach failed", pid, tmpdir));| path 
>> can never be taken, because either the |if| statement evaluates to 
>> |true|, or the |else if|.
>>
>> I'm not sure if we can do any better than always falling back to 
>> |/tmp|? But if anyone has suggestions, I'm certainly happy to try it out.
>>
>> ?
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2093378574__;Iw!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wAeEv03g$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UD2AU4WJYYSI7427LZAO5CTAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGM3TQNJXGQ__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wuDyNaeA$>.
>> You are receiving this because you were mentioned.Message ID: 
>> <openjdk/jdk/pull/19055/c2093378574 at github.com>
>>
>

-- 
Sebastian L?vdahl
Senior Software Architect, Hibox Systems -https://www.hibox.tv
sebastian.lovdahl at hibox.tv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240506/a222199e/attachment-0001.htm>

From duke at openjdk.org  Mon May  6 16:17:51 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 6 May 2024 16:17:51 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com>
Message-ID: <tZpKWUR8cOZcw6oWRwigC1G2N0FJj1lZ_pmszyAI_Lg=.79b89992-1405-4d0a-a11b-d086b55c8fbb@github.com>

On Fri, 3 May 2024 17:40:54 GMT, jdoylei <duke at openjdk.org> wrote:

> > I think it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.
> 
> @slovdahl - In that test case (target JVM process has more privileges), where is the attach file created? Does jcmd end up writing it to `/tmp`? Or does `/proc/<pid>/cwd` work? Just curious whether the elevated-privileges scenario affects the attach file and socket file locations equally.

Yes, the attach file ends up in `/tmp`. Elevated privileges means that at least `/proc/<pid>/root`, `/proc/<pid>/cwd` and `/proc/<pid>/exe` are unreadable.


slovdahl at ubuntu2204:/proc/942992$ ls -lh cwd root 
ls: cannot read symbolic link 'cwd': Permission denied
ls: cannot read symbolic link 'root': Permission denied
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  6 19:06 cwd
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  6 19:06 root


> regardless I think the added check for mnt ns comparison "adds value" by
> expressing the constraints explicitly vs comparing pid & ns pid

Yep, agreed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096419600

From larry.cable at oracle.com  Mon May  6 16:32:33 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 6 May 2024 09:32:33 -0700
Subject: [External] : Re: [openjdk/jdk] 8327114: Attach in Linux may have
 wrong behaviour when pid == ns_pid (Kubernetes debug container) (PR
 #19055)
In-Reply-To: <4f7b3865-951c-472d-8b89-3abc7c0d0350@hibox.tv>
References: <openjdk/jdk/pull/19055@github.com>
 <openjdk/jdk/pull/19055/c2093378574@github.com>
 <08bd0044-82bf-4cf4-a909-e5f1e9ef6506@oracle.com>
 <4f7b3865-951c-472d-8b89-3abc7c0d0350@hibox.tv>
Message-ID: <984d5c25-9fd1-4931-916f-70e772fda07a@oracle.com>

I'll send you another diff, I have something that I think may work...

On 5/6/24 9:16 AM, Sebastian L?vdahl wrote:
> Yep, that sounds reasonable. I'll try to work something out along 
> these lines, thanks for the input!
>
> Unfortunately, /proc/<attachee>/cwd is also restricted in the same way 
> as /proc/<attachee>/root is.
>
> /Sebastian
>
> On 2024-05-05 00:06, Laurence Cable wrote:
>> so I think to summarize the logic we require:
>>
>> 1) if we can determine that the attacher and attachee occupy the same 
>> mnt ns (/proc/<attacher>/ns/mnt == /proc/<attachee>/ns/mnt), return 
>> "/tmp"
>> 2) if they are not in the same mnt ns:
>> ??? - test the /proc/<attachee>/root/tmp path for readability, if it 
>> is, return that
>> ??? - if it is not readable (its either secured with elevated privs 
>> and it exists) return "/tmp" which may still fail because they are in 
>> fact not in the same mnt ns
>>
>> what about /proc/<attachee>/cwd?
>>
>> - Larry
>>
>>
>> On 5/3/24 9:43 AM, Sebastian L?vdahl wrote:
>>>
>>> Thanks for the patch @larry-cable 
>>> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5xDccS1BA$>, 
>>> much appreciated! I really like this idea.
>>>
>>> I tried it out a bit locally. These cases seem to work:
>>>
>>>   * attaching to a process running on the same host (PID and mount
>>>     namespace the same)
>>>   * attaching as root from the host to a JVM inside a container
>>>   * attaching from a sidecar container to a JVM in another container
>>>
>>> Unfortunately, attaching to a JVM process running as the same user 
>>> in the same PID and mount namespace but one that has elevated 
>>> privileges no longer works (the case that JDK-8226919 fixed). That 
>>> case ends up failing like this with the patch:
>>>
>>> |slovdahl at ubuntu2204:~/reproducer$ 
>>> /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 
>>> 1751545 VM.version 1751545: java.io.IOException: Unable to access 
>>> root directory /proc/1751545/root of target process 1751545 at 
>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284) 
>>> at 
>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229) 
>>> at 
>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86) 
>>> at 
>>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) 
>>> at 
>>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) 
>>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) 
>>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) |
>>>
>>> I /think/ it boils down to the same reason as why the fix for 
>>> JDK-8226919 was needed in the first place - a non-root user cannot 
>>> read the symlinks in |/proc/<pid>/ns| for a process running with 
>>> more privileges even though it's run by the same non-root user.
>>>
>>> |slovdahl at ubuntu2204:/proc/1751545/ns$ ls -lh ls: cannot read 
>>> symbolic link 'net': Permission denied ls: cannot read symbolic link 
>>> 'uts': Permission denied ls: cannot read symbolic link 'ipc': 
>>> Permission denied ls: cannot read symbolic link 'pid': Permission 
>>> denied ls: cannot read symbolic link 'pid_for_children': Permission 
>>> denied ls: cannot read symbolic link 'user': Permission denied ls: 
>>> cannot read symbolic link 'mnt': Permission denied ls: cannot read 
>>> symbolic link 'cgroup': Permission denied ls: cannot read symbolic 
>>> link 'time': Permission denied ls: cannot read symbolic link 
>>> 'time_for_children': Permission denied total 0 lrwxrwxrwx 1 slovdahl 
>>> slovdahl 0 maj 3 19:28 cgroup lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>>> 19:28 ipc lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:27 mnt 
>>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 net lrwxrwxrwx 1 
>>> slovdahl slovdahl 0 maj 3 19:28 pid lrwxrwxrwx 1 slovdahl slovdahl 0 
>>> maj 3 19:28 pid_for_children lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>>> 19:28 time lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>>> time_for_children lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 user 
>>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 uts 
>>> slovdahl at ubuntu2204:/proc/1751545/ns$ sudo ls -lh total 0 lrwxrwxrwx 
>>> 1 slovdahl slovdahl 0 maj 3 19:28 cgroup -> 'cgroup:[4026531835]' 
>>> lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 ipc -> 
>>> 'ipc:[4026531839]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:27 mnt 
>>> -> 'mnt:[4026533862]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>>> net -> 'net:[4026531840]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>>> 19:28 pid -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 
>>> 3 19:28 pid_for_children -> 'pid:[4026531836]' lrwxrwxrwx 1 slovdahl 
>>> slovdahl 0 maj 3 19:28 time -> 'time:[4026531834]' lrwxrwxrwx 1 
>>> slovdahl slovdahl 0 maj 3 19:28 time_for_children -> 
>>> 'time:[4026531834]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 19:28 
>>> user -> 'user:[4026531837]' lrwxrwxrwx 1 slovdahl slovdahl 0 maj 3 
>>> 19:28 uts -> 'uts:[4026531838]' |
>>>
>>> FWIW, my IntelliJ also highlighted the fact that the suggested patch 
>>> contains unreachable code. The |else throw new 
>>> IOException(String.format("target process:%d and this do not share 
>>> common mount namespace for: %s attach failed", pid, tmpdir));| path 
>>> can never be taken, because either the |if| statement evaluates to 
>>> |true|, or the |else if|.
>>>
>>> I'm not sure if we can do any better than always falling back to 
>>> |/tmp|? But if anyone has suggestions, I'm certainly happy to try it 
>>> out.
>>>
>>> ?
>>> Reply to this email directly, view it on GitHub 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2093378574__;Iw!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wAeEv03g$>, 
>>> or unsubscribe 
>>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UD2AU4WJYYSI7427LZAO5CTAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGM3TQNJXGQ__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wuDyNaeA$>.
>>> You are receiving this because you were mentioned.Message ID: 
>>> <openjdk/jdk/pull/19055/c2093378574 at github.com>
>>>
>>
>
> -- 
> Sebastian L?vdahl
> Senior Software Architect, Hibox Systems -https://www.hibox.tv
> sebastian.lovdahl at hibox.tv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240506/e954dc67/attachment-0001.htm>

From duke at openjdk.org  Mon May  6 17:29:05 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 6 May 2024 17:29:05 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:

  Reworked attach logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19055/files
  - new: https://git.openjdk.org/jdk/pull/19055/files/d37423fc..d3e26a0c

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

  Stats: 71 lines in 1 file changed: 36 ins; 12 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/19055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055

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

From duke at openjdk.org  Mon May  6 17:37:53 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 6 May 2024 17:37:53 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
Message-ID: <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com>

On Mon, 6 May 2024 17:29:05 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworked attach logic

I pushed an updated attempt at this now with d3e26a0c444e06ba9757fd528d72d83f56cd098b. Local testing and `make test TEST="jtreg:test/hotspot/jtreg/containers"` + `make test TEST="jtreg:test/hotspot/jtreg/serviceability"` indicate that all the known use-cases work.

Still eager to see what you come up with @larry-cable. `createAttachFile` could still be improved for example. And I would also be interested in looking into writing some test for the elevated privileges case.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096564990

From duke at openjdk.org  Mon May  6 18:33:58 2024
From: duke at openjdk.org (Larry Cable)
Date: Mon, 6 May 2024 18:33:58 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
Message-ID: <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>

On Mon, 6 May 2024 17:29:05 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworked attach logic

On 5/6/24 10:35 AM, Sebastian L?vdahl wrote:
>
> I pushed an updated attempt at this now with d3e26a0 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d3e26a0c444e06ba9757fd528d72d83f56cd098b__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svPHZrq9ZQ$>. 
> Local testing and |make test 
> TEST="jtreg:test/hotspot/jtreg/containers"| + |make test 
> TEST="jtreg:test/hotspot/jtreg/serviceability"| indicate that all the 
> known use-cases work.
>
> Still eager to see what you come up with @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNMPdGFLg$>. 
> |createAttachFile| could still be improved for example. And I would 
> also be interested in looking into writing some test for the elevated 
> privileges case.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2096564990__;Iw!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNUwHWtZA$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGOTAXCKY2TO2OBDDZA65N5AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGU3DIOJZGA__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svO2ymONGw$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>


 ?/*
diff --git 
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
index 81d4fd259ed..c148dbd61b7 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -34,6 +34,7 @@
 ?import java.nio.file.Path;
 ?import java.nio.file.Paths;
 ?import java.nio.file.Files;
+import java.util.Optional;

 ?import static java.nio.charset.StandardCharsets.UTF_8;

@@ -46,8 +47,28 @@ public class VirtualMachineImpl extends 
HotSpotVirtualMachine {
 ???? // location is the same for all processes, otherwise the tools
 ???? // will not be able to find all Hotspot processes.
 ???? // Any changes to this needs to be synchronized with HotSpot.
-??? private static final String tmpdir = "/tmp";
+??? private static final Path TMPDIR = Path.of("/tmp");
+
+??? private static final Path PROC?? = Path.of("/proc");
+??? private static final Path NS_MNT = Path.of("ns/mnt");
+??? private static final Path SELF?? = PROC.resolve("self");
+??? private static final Path TMP??? = Path.of("tmp");
+
+??? private static final Optional<Path> SELF_MNT_NS;
+
+??? static {
+??????? Path mountns = null;
+??????? try {
+??????????? mountns = Files.readSymbolicLink(SELF.resolve(NS_MNT));
+??????? } catch (IOException _) {
+??? ??? // do nothing
+??????? } finally {
+??????????? SELF_MNT_NS = Optional.ofNullable(mountns);
+??????? }
+??? }
+
 ???? String socket_path;
+
 ???? /**
 ????? * Attaches to the target VM
 ????? */
@@ -235,24 +256,36 @@ private File createAttachFile(int pid, int ns_pid) 
throws IOException {
 ???? }

 ???? private String findTargetProcessTmpDirectory(int pid, int ns_pid) 
throws IOException {
-??????? String root;
-??????? if (pid != ns_pid) {
+??????? final var procPid = PROC.resolve(Integer.toString(pid));
+
+??????? Optional<Path> tgtMountNS = Optional.empty();
+
+??????? try {
+??????????? tgtMountNS = 
Optional.ofNullable(Files.readSymbolicLink(procPid.resolve(NS_MNT))); // 
attempt to read the tgt's mnt ns id...
+??????? } catch (IOException _) { // if we fail to read the tgt's mnt 
ns id then we either dont have access or it no longer exists!
+??????????? if (!Files.exists(procPid)) throw new 
IOException(String.format("unable to attach, %s non-existent! process: 
%d terminated", procPid, pid));
+
+??????????? // ok so if we get here we have failed to read the tgt's 
mnt ns, but the tgt process still exists ... we do not have privs to 
read its procfs
+??????? }
+
+??? ??? final boolean sameMountNS = SELF_MNT_NS.isPresent() && 
SELF_MNT_NS.equals(tgtMountNS); // will be false? if we did not read the 
tgt's mnt ns
+
+??????? if (!sameMountNS || pid != ns_pid) {
 ???????????? // A process may not exist in the same mount namespace as 
the caller, e.g.
 ???????????? // if we are trying to attach to a JVM process inside a 
container.
 ???????????? // Instead, attach relative to the target root filesystem 
as exposed by
 ???????????? // procfs regardless of namespaces.
-??????????? String procRootDirectory = "/proc/" + pid + "/root";
-??????????? if (!Files.isReadable(Path.of(procRootDirectory))) {
-??????????????? throw new IOException(
-??????????????????????? String.format("Unable to access root directory 
%s " +
-????????????????????????? "of target process %d", procRootDirectory, pid));
+??????????? final var procRootDirectory = procPid.resolve("root");
+
+??????????? if (Files.isReadable(procRootDirectory))
+??????????????? return procRootDirectory.resolve(TMP).toString();
+??????????? else if (Files.exists(procPid)) { // process is still 
alive... so its a permissions issue... fallback but this may also fail
+??????????????? return TMPDIR.toString();
+??????????? } else {
+??????????????? throw new IOException(String.format("Unable to access 
root directory %s " + "of target process %d", 
procRootDirectory.toString(), pid));
 ???????????? }
-
-??????????? root = procRootDirectory + "/" + tmpdir;
-??????? } else {
-??????????? root = tmpdir;
-??????? }
-??????? return root;
+??????? } else
+??????????? return TMPDIR.toString(); // we are in the same mnt ns
 ???? }

 ???? /*

--------------ZiY5EhYyDoaC0Fy7Oxy0DC0T
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/6/24 10:35 AM, Sebastian L?vdahl
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      <p dir="auto">I pushed an updated attempt at this now with <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/openjdk/jdk/commit/d3e26a0c444e06ba9757fd528d72d83f56cd098b/hovercard" href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d3e26a0c444e06ba9757fd528d72d83f56cd098b__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svPHZrq9ZQ$" moz-do-not-send="true"><tt>d3e26a0</tt></a>. Local testing and
        <code class="notranslate">make test
          TEST=&quot;jtreg:test/hotspot/jtreg/containers&quot;</code> + <code class="notranslate">make test
          TEST=&quot;jtreg:test/hotspot/jtreg/serviceability&quot;</code> indicate
        that all the known use-cases work.</p>
      <p dir="auto">Still eager to see what you come up with <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNMPdGFLg$" ***@***.***</a>. <code class="notranslate">createAttachFile</code> could still be
        improved for example. And I would also be interested in looking
        into writing some test for the elevated privileges case.</p>
      <p>?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2096564990__;Iw!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNUwHWtZA$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGOTAXCKY2TO2OBDDZA65N5AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGU3DIOJZGA__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svO2ymONGw$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img alt="" moz-do-not-send="true" width="1" height="1"><span>Message ID:
          <span>&lt;openjdk/jdk/pull/19055/c2096564990</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
    </blockquote>
    <br>
    <br>
    &nbsp;/*<br>
    diff --git
    a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java<br>
    index 81d4fd259ed..c148dbd61b7 100644<br>
    ---
    a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java<br>
    +++
    b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java<br>
    @@ -34,6 +34,7 @@<br>
    &nbsp;import java.nio.file.Path;<br>
    &nbsp;import java.nio.file.Paths;<br>
    &nbsp;import java.nio.file.Files;<br>
    +import java.util.Optional;<br>
    &nbsp;<br>
    &nbsp;import static java.nio.charset.StandardCharsets.UTF_8;<br>
    &nbsp;<br>
    @@ -46,8 +47,28 @@ public class VirtualMachineImpl extends
    HotSpotVirtualMachine {<br>
    &nbsp;&nbsp;&nbsp;&nbsp; // location is the same for all processes, otherwise the tools<br>
    &nbsp;&nbsp;&nbsp;&nbsp; // will not be able to find all Hotspot processes.<br>
    &nbsp;&nbsp;&nbsp;&nbsp; // Any changes to this needs to be synchronized with HotSpot.<br>
    -&nbsp;&nbsp;&nbsp; private static final String tmpdir = &quot;/tmp&quot;;<br>
    +&nbsp;&nbsp;&nbsp; private static final Path TMPDIR = Path.of(&quot;/tmp&quot;);<br>
    +<br>
    +&nbsp;&nbsp;&nbsp; private static final Path PROC&nbsp;&nbsp; = Path.of(&quot;/proc&quot;);<br>
    +&nbsp;&nbsp;&nbsp; private static final Path NS_MNT = Path.of(&quot;ns/mnt&quot;);<br>
    +&nbsp;&nbsp;&nbsp; private static final Path SELF&nbsp;&nbsp; = PROC.resolve(&quot;self&quot;);<br>
    +&nbsp;&nbsp;&nbsp; private static final Path TMP&nbsp;&nbsp;&nbsp; = Path.of(&quot;tmp&quot;);<br>
    +<br>
    +&nbsp;&nbsp;&nbsp; private static final Optional&lt;Path&gt; SELF_MNT_NS;<br>
    +<br>
    +&nbsp;&nbsp;&nbsp; static {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Path mountns = null;<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mountns = Files.readSymbolicLink(SELF.resolve(NS_MNT));<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (IOException _) {<br>
    +&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; // do nothing<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } finally {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SELF_MNT_NS = Optional.ofNullable(mountns);<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
    +&nbsp;&nbsp;&nbsp; }<br>
    +<br>
    &nbsp;&nbsp;&nbsp;&nbsp; String socket_path;<br>
    +<br>
    &nbsp;&nbsp;&nbsp;&nbsp; /**<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Attaches to the target VM<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */<br>
    @@ -235,24 +256,36 @@ private File createAttachFile(int pid, int
    ns_pid) throws IOException {<br>
    &nbsp;&nbsp;&nbsp;&nbsp; }<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp; private String findTargetProcessTmpDirectory(int pid, int
    ns_pid) throws IOException {<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String root;<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (pid != ns_pid) {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; final var procPid = PROC.resolve(Integer.toString(pid));<br>
    +<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Optional&lt;Path&gt; tgtMountNS = Optional.empty();<br>
    +<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tgtMountNS =
    Optional.ofNullable(Files.readSymbolicLink(procPid.resolve(NS_MNT)));
    // attempt to read the tgt's mnt ns id...<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (IOException _) { // if we fail to read the tgt's
    mnt ns id then we either dont have access or it no longer exists!<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (!Files.exists(procPid)) throw new
    IOException(String.format(&quot;unable to attach, %s non-existent!
    process: %d terminated&quot;, procPid, pid));<br>
    +<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // ok so if we get here we have failed to read the
    tgt's mnt ns, but the tgt process still exists ... we do not have
    privs to read its procfs<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
    +<br>
    +&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; final boolean sameMountNS = SELF_MNT_NS.isPresent()
    &amp;&amp; SELF_MNT_NS.equals(tgtMountNS); // will be false&nbsp; if we
    did not read the tgt's mnt ns<br>
    +<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (!sameMountNS || pid != ns_pid) {<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // A process may not exist in the same mount namespace
    as the caller, e.g.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // if we are trying to attach to a JVM process inside a
    container.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Instead, attach relative to the target root
    filesystem as exposed by<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // procfs regardless of namespaces.<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String procRootDirectory = &quot;/proc/&quot; + pid + &quot;/root&quot;;<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (!Files.isReadable(Path.of(procRootDirectory))) {<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new IOException(<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String.format(&quot;Unable to access root
    directory %s &quot; +<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;of target process %d&quot;,
    procRootDirectory, pid));<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; final var procRootDirectory = procPid.resolve(&quot;root&quot;);<br>
    +<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (Files.isReadable(procRootDirectory))<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return procRootDirectory.resolve(TMP).toString();<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if (Files.exists(procPid)) { // process is still
    alive... so its a permissions issue... fallback but this may also
    fail<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return TMPDIR.toString();<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new IOException(String.format(&quot;Unable to
    access root directory %s &quot; + &quot;of target process %d&quot;,
    procRootDirectory.toString(), pid));<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
    -<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; root = procRootDirectory + &quot;/&quot; + tmpdir;<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; root = tmpdir;<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return root;<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else<br>
    +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return TMPDIR.toString(); // we are in the same mnt ns<br>
    &nbsp;&nbsp;&nbsp;&nbsp; }<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp; /*<br>
    <br>
  </body>
</html>

--------------ZiY5EhYyDoaC0Fy7Oxy0DC0T--

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096660046

From matsaave at openjdk.org  Mon May  6 20:50:02 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 6 May 2024 20:50:02 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in relocation
 bitmap
Message-ID: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>

The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.

These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

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

Commit messages:
 - Merge branch 'master' into pointer_to_offset_8329418
 - Cleanup
 - Corrected SA
 - Editing SA
 - Fixed dynamic dumping
 - Now works with -Xshare:on
 - Adjusted serialization
 - Serializing offsets
 - 8329418: Replace pointers to tables with offsets in relocation bitmap

Changes: https://git.openjdk.org/jdk/pull/19107/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329418
  Stats: 121 lines in 8 files changed: 69 ins; 23 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/19107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19107/head:pull/19107

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

From cjplummer at openjdk.org  Mon May  6 21:22:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 21:22:05 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with eight additional commits since the last revision:

 - Minor comment fix in debugMonitorCreate()
 - Don't do anything in assertIsCurrentThread() if asserts are disabled
 - Print threads names instead of addresses in assertIsCurrentThread()
 - Renamed thread -> savedOwnerThread and entryCount -> savedEntryCount.
 - pass already fetched current_thread to assertIsCurrentThread()
 - dbgRawMonitor reference should be dbg_monitor->monitor in dumpRawMonitors()
 - Free localrefs allocated by GetThreadInfo().
 - Optimize loop iterations during rank verification.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/bcb92b59..ece5f34f

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

  Stats: 46 lines in 1 file changed: 19 ins; 11 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044

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

From cjplummer at openjdk.org  Mon May  6 21:26:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 21:26:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
Message-ID: <FYrUs3Tn0cJnf0dDLTR9crROneApTO3H3Y0QcOmHxdA=.8d7c6f70-0a3b-42da-8a56-4e44f3df1a06@github.com>

On Thu, 2 May 2024 21:00:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1204:
>> 
>>> 1202:     // Need to lock during initialization so verifyMonitorRank() can be guaranteed that
>>> 1203:     // if the monitor field is set, then the monitor if fully initialized. More specifically,
>>> 1204:     // that the rank field has been set.
>> 
>> rank for all monitors can be set in `util_initialize()`:
>> 
>> for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
>>   dbg_monitors[i]->rank = i;
>> }
>
> Ok.

I decided not to make this change. It was a bit disruptive with the need for forward declarations. Plus I wasn't convinced I wouldn't still need the locking since there is also the assignment of the name field (although that is only used if something has gone wrong) and also I was a little worried that tearing could happen on some platforms (a partial ptr value is read in), although not on any platform that we support. I did update the comment to make it less specific about the rank field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591571349

From cjplummer at openjdk.org  Mon May  6 21:34:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 21:34:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
Message-ID: <EFjzJ9HNfIV68tTyExflb1XJackNW5XteZMKSvdMZoo=.c5f67566-163e-4a6d-a0b6-1cabd5c3a688@github.com>

On Thu, 2 May 2024 21:09:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1243:
>> 
>>> 1241:     error = JVMTI_FUNC_PTR(gdata->jvmti,GetThreadInfo)
>>> 1242:             (gdata->jvmti, thread, &info);
>>> 1243:     return info.name;
>> 
>> Need to delete JNI reference info.thread_group and info.jthreadGroup (if not NULL)
>
> Did you mean info.context_class_loader, not info.jthreadGroup?
> 
> It looks like elsewhere when we call GetThreadInfo it is bracketed with the WITH_LOCAL_REFS macro to automatically push/pop a local refs frame, although it is only setting the size to 1, which seems like a bug. I'll do the same here.

Fixed. I also filed [JDK-8331747](https://bugs.openjdk.org/browse/JDK-8331747) to fix pre-existing cases of calling GetThreadInfo() and not freeing up the local refs.

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1262:
>> 
>>> 1260:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
>>> 1261:         DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
>>> 1262:         if (dbg_monitor == NULL) {
>> 
>> Should be `dbg_monitor->monitor`
>
> ok

Fixed.

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1279:
>> 
>>> 1277:         return; // This assert is not reliable if the VM is exiting
>>> 1278:     }
>>> 1279:     jthread current_thread = threadControl_currentThread();
>> 
>> Looks like all callers of the `assertIsCurrentThread()` have reference to the current thread. Maybe pass it as argument?
>
> Ok. There were a few changes w.r.t. when this API is called, as was when the callers have access to the current thread, so I that's why I ended up not passing it in.

Fixed.

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1281:
>> 
>>> 1279:     jthread current_thread = threadControl_currentThread();
>>> 1280:     if (!isSameObject(env, thread, current_thread)) {
>>> 1281:         tty_message("ERROR: Threads not the same: %p %p\n", thread, current_thread);
>> 
>> Not sure the addresses provide useful information. Maybe print thread names?
>
> ok

Fixed.

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1294:
>> 
>>> 1292:     // has a higher rank than the monitor we are about to enter.
>>> 1293:     DebugRawMonitorRank i;
>>> 1294:     for (i = 0; i < NUM_DEBUG_RAW_MONITORS; i++) {
>> 
>> No need to check monitors from the beginning.
>> Should be enough to check starting from `min(rank, FIRST_LEAF_DEBUG_RAW_MONITOR)`
>
> I originally started at `rank`, but then when I added the 2nd of the two checks below I switched to 0, but your min suggestion should be optimal.

Fixed.

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1470:
>> 
>>> 1468: 
>>> 1469:     // Assert that the current thread owns this monitor.
>>> 1470:     assertIsCurrentThread(getEnv(), dbg_monitor->ownerThread);
>> 
>> reading ownerThread (and other) fields without dbgRawMonitor is not MT-safe (it's not atomic)
>
> It is safe if you are the owner of the monitor.  So what that means is that this assert could potentially crash, but only if you are not the owner, which means if it didn't crash then it would have asserted. However, even when asserts are disabled, isSameObject() is still executed, and that's were the crash would happen. assertIsCurrentThread() really should be a no-op if asserts are not enabled. But even if that change is not made, it still would only crash if something bad was going on since the current thread should always own the monitor.

I fixed the issue with executing assertIsCurrentThread even when asserts are disabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591577188
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591577385
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591577559
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591577701
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591577876
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591578574

From cjplummer at openjdk.org  Mon May  6 21:44:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 21:44:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
Message-ID: <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>

On Thu, 2 May 2024 21:02:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1231:
>> 
>>> 1229:     }
>>> 1230: 
>>> 1231:     dbg_monitor->monitor = NULL;
>> 
>> I think it would be better to protect this with dbgRawMonitor
>
> I don't see how that helps. Access to the field is not protected.

I guess there could be a race if one thread is destroying this monitor while another is trying to use it. Thus a thread could be doing something like a RawMonitorEnter in the middle of (or after) the monitor being destroyed. Fixing that would require holding dbgRawMonitor during RawMonitorEnter, and that would cause deadlocks all over the place. Also, this same potential issue exists already, but doesn't seem to ever arise. It seems we only call debugMonitorDestroy for cmdQueueLock. Not sure why that is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591586968

From cjplummer at openjdk.org  Mon May  6 22:21:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 22:21:53 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v9]
In-Reply-To: <7Aud9EX-Q09Bx3MmZjM182gBp9sDmbvIt7rSmtBa1FM=.cc43a81c-7431-484d-9eae-295da93c9a52@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <7Aud9EX-Q09Bx3MmZjM182gBp9sDmbvIt7rSmtBa1FM=.cc43a81c-7431-484d-9eae-295da93c9a52@github.com>
Message-ID: <3x1oThcCfOj6FR0ZJoH5ipYkrHTFAzrgJXm69Tggb8k=.83dba355-787a-4f05-a721-df5aee8fd810@github.com>

On Sat, 4 May 2024 03:45:31 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

In SA I see references to heapRegionIterate() that possibly should be renamed.

I noticed that the HeapRegionManager and HeapRegionClosure classes were not renamed (in the hotspot source). Is this intentional or an oversite?

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

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2041768479

From sspitsyn at openjdk.org  Mon May  6 22:30:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 6 May 2024 22:30:51 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <EFjzJ9HNfIV68tTyExflb1XJackNW5XteZMKSvdMZoo=.c5f67566-163e-4a6d-a0b6-1cabd5c3a688@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <EFjzJ9HNfIV68tTyExflb1XJackNW5XteZMKSvdMZoo=.c5f67566-163e-4a6d-a0b6-1cabd5c3a688@github.com>
Message-ID: <6wc7aRivlNRWo4-HAM4DGYfZ_OvpHjeyNJgj5Of7yFw=.654e5267-a083-4b92-b692-234e3cc2f805@github.com>

On Mon, 6 May 2024 21:31:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I originally started at `rank`, but then when I added the 2nd of the two checks below I switched to 0, but your min suggestion should be optimal.
>
> Fixed.

I was about to post a similar comment but found it has been already fixed in the update. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591618748

From cjplummer at openjdk.org  Mon May  6 22:37:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 May 2024 22:37:53 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap
In-Reply-To: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
Message-ID: <QpWgz-Nud2v8Qbnn9SL6Dr408HrIkUINRooic9sujBk=.25e63d46-4a50-4fd8-926c-00b4846de597@github.com>

On Mon, 6 May 2024 17:05:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
> 
> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 186:

> 184:       // };
> 185:       //
> 186:       // The following loop compues the following

Since there are lot of comments after this point, maybe the wording should instead be "The loop below...". Also, should be "computes"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 216:

> 214:       for (int i=0; i < metadataTypeArray.length; i++) {
> 215:         long vtable_offset = vtablesIndex.getJLongAt(i * addressSize); // long offset = _index[i]
> 216:         System.out.printf("Offset: %x\n", vtable_offset);

Remove printf().

test/hotspot/jtreg/serviceability/sa/TestSysProps.java line 68:

> 66:         }
> 67:         if (numProps != expectedCount) {
> 68:             throw new RuntimeException("Wrong number of " + cmdName + " properties: " + numProps + " Expected: " + expectedCount);

I think it would be good to add parenthesis around the extra output you added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1591620087
PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1591619830
PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1591620843

From cjplummer at openjdk.org  Tue May  7 00:33:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 00:33:07 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v3]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <25edz64vcMa9E0VUtpwIB8io3V2MWE6c76zN2QWVMd4=.49183d76-0262-4822-8c89-82551ea57f95@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Call verifyMonitorRank() when doing a wait since wait does an exit and enter, so we should do the same rank check that we do during an enter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/ece5f34f..c782279b

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

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

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

From sspitsyn at openjdk.org  Tue May  7 00:33:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 May 2024 00:33:08 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
Message-ID: <OeHw6OVNore6CaEyJSZNttj9BcVPMGIOqCD3vOcmoVY=.cdfb01d6-93bd-49fc-904c-8a01ce1eeb74@github.com>

On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - Minor comment fix in debugMonitorCreate()
>  - Don't do anything in assertIsCurrentThread() if asserts are disabled
>  - Print threads names instead of addresses in assertIsCurrentThread()
>  - Renamed thread -> savedOwnerThread and entryCount -> savedEntryCount.
>  - pass already fetched current_thread to assertIsCurrentThread()
>  - dbgRawMonitor reference should be dbg_monitor->monitor in dumpRawMonitors()
>  - Free localrefs allocated by GetThreadInfo().
>  - Optimize loop iterations during rank verification.

Chris, I'm looking at this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2097141567

From cjplummer at openjdk.org  Tue May  7 00:33:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 00:33:08 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
Message-ID: <pDgSpkX7IUjJC6IGg4HsKBqnRN6_PjHNB4m8_BeLOxE=.f14b7a70-b92a-4b8f-8969-4cc225279518@github.com>

On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - Minor comment fix in debugMonitorCreate()
>  - Don't do anything in assertIsCurrentThread() if asserts are disabled
>  - Print threads names instead of addresses in assertIsCurrentThread()
>  - Renamed thread -> savedOwnerThread and entryCount -> savedEntryCount.
>  - pass already fetched current_thread to assertIsCurrentThread()
>  - dbgRawMonitor reference should be dbg_monitor->monitor in dumpRawMonitors()
>  - Free localrefs allocated by GetThreadInfo().
>  - Optimize loop iterations during rank verification.

I added a verifyMonitorRank() when doing a debugMonitorWait() since wait does an exit and enter, so we should do the same rank check that we do during an enter. I was a bit worried that we might be doing wait() while holding higher ranking lock, especially given how getLocks() pro-actively grabs locks before they are needed, but all tests (surprisingly) passed after this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2097144186

From cjplummer at openjdk.org  Tue May  7 00:33:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 00:33:08 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v3]
In-Reply-To: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
Message-ID: <gQ3cTvMvWwNY8ooZu_zc1xbRuifH2qWMnA44Gi9wygA=.8f10e2f8-ef32-4568-af4e-385774d8b0f1@github.com>

On Thu, 2 May 2024 21:14:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1289:
>> 
>>> 1287: 
>>> 1288: static void
>>> 1289: verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread thread)
>> 
>> please add a comment that the function should be called under dbgRawMonitor lock (also for other functions which assume this)
>
> ok. I was also thinking of setting a static that contains the jthread of the thread that holds the lock, and we can assert it is held.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591678643

From sspitsyn at openjdk.org  Tue May  7 00:35:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 May 2024 00:35:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v2]
In-Reply-To: <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <q4JY2oMuRzPN2_TvaBUHhnFg7M6X7iOipLhPDlXey6E=.c301d44d-3575-4157-b430-9d912d85e6ff@github.com>
Message-ID: <kK51bTrsKJs1XQe5YXgIzYXpnZMx-pFOTnutrhVybnQ=.454d5835-6a72-4fba-ac2b-78ee19d00c2f@github.com>

On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - Minor comment fix in debugMonitorCreate()
>  - Don't do anything in assertIsCurrentThread() if asserts are disabled
>  - Print threads names instead of addresses in assertIsCurrentThread()
>  - Renamed thread -> savedOwnerThread and entryCount -> savedEntryCount.
>  - pass already fetched current_thread to assertIsCurrentThread()
>  - dbgRawMonitor reference should be dbg_monitor->monitor in dumpRawMonitors()
>  - Free localrefs allocated by GetThreadInfo().
>  - Optimize loop iterations during rank verification.

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1203:

> 1201: 
> 1202:     // Need to lock during initialization so verifyMonitorRank() can be guaranteed that
> 1203:     // if the monitor field is not NULL, then the monitor if fully initialized.

Nit: It looks like a typo: "the monitor if fully" => "the monitor is fully"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1591680028

From prappo at openjdk.org  Tue May  7 11:58:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:58:16 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>

Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

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

Commit messages:
 - Initial commit

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

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

From prappo at openjdk.org  Tue May  7 12:05:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 12:05:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <rwFuWs_IIJsPhKj5T4_C-CwJaeB4dCDHCAVBiLxS_ik=.3c274157-f47a-4a9f-94e8-fbdf03cd265e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This PR is standalone as opposed to dependent because the https://github.com/openjdk/jdk/pull/18787 dependency currently has a merge conflict, which complicates the required workflow.

This comment serves as a reminder to merge master into this PR once https://github.com/openjdk/jdk/pull/18787 has been integrated. If we don't do that, Skara will likely create a backport issue:

> (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2098246931

From matsaave at openjdk.org  Tue May  7 15:06:53 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 May 2024 15:06:53 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap
In-Reply-To: <QpWgz-Nud2v8Qbnn9SL6Dr408HrIkUINRooic9sujBk=.25e63d46-4a50-4fd8-926c-00b4846de597@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
 <QpWgz-Nud2v8Qbnn9SL6Dr408HrIkUINRooic9sujBk=.25e63d46-4a50-4fd8-926c-00b4846de597@github.com>
Message-ID: <l-kYnE6TznjEI7JQVaPalL6WqZIIWGXY68i9sMU13Fg=.15d2de9a-5256-4959-af29-a12438ece9f8@github.com>

On Mon, 6 May 2024 22:32:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
>> 
>> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.
>
> test/hotspot/jtreg/serviceability/sa/TestSysProps.java line 68:
> 
>> 66:         }
>> 67:         if (numProps != expectedCount) {
>> 68:             throw new RuntimeException("Wrong number of " + cmdName + " properties: " + numProps + " Expected: " + expectedCount);
> 
> I think it would be good to add parenthesis around the extra output you added.

This was an accidental leftover from debugging, I didn't intend for this to be part of the change. I should revert this since it's beyond the scope of this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1592648930

From larry.cable at oracle.com  Tue May  7 16:33:26 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Tue, 7 May 2024 09:33:26 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
 <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com>
Message-ID: <5edb3aa8-28c5-43f8-a4d3-a2da26de30f1@oracle.com>

just a thought ... what if the code were to recurse "up" the process 
tree if the target JVM had elevated privs (and its /proc/... was not 
accessible), in order to find an
ancestor whose /proc was accessible, since the JVM itself does not 
modify its pid or mnt namespaces (or capabilities) only an ancestor 
process could elevate the JVM.

once an ancestor with a readable /proc/.../root/tmp was located, that 
"proc" could be interrogated to determine if the target JVM was present 
in its
namespace by validating that the target nspid was present in therein, 
then the attach could use the /proc/<ancestor>/root/tmp as the 
"attach"directory path instead
of falling back on "/tmp" which potentially is not in the same mnt ns as 
the attacher?

of course the recursion would stop at "1" ...

thoughts?

- Larry

On 5/6/24 10:37 AM, Sebastian L?vdahl wrote:
> On Mon, 6 May 2024 17:29:05 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:
>
>>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Reworked attach logic
> I pushed an updated attempt at this now with d3e26a0c444e06ba9757fd528d72d83f56cd098b. Local testing and `make test TEST="jtreg:test/hotspot/jtreg/containers"` + `make test TEST="jtreg:test/hotspot/jtreg/serviceability"` indicate that all the known use-cases work.
>
> Still eager to see what you come up with @larry-cable. `createAttachFile` could still be improved for example. And I would also be interested in looking into writing some test for the elevated privileges case.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096564990


From matsaave at openjdk.org  Tue May  7 16:38:23 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 May 2024 16:38:23 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v2]
In-Reply-To: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
Message-ID: <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>

> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
> 
> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Chris comments and cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19107/files
  - new: https://git.openjdk.org/jdk/pull/19107/files/c925025e..d40afef9

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

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

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

From cjplummer at openjdk.org  Tue May  7 17:45:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 17:45:54 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64
In-Reply-To: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
Message-ID: <mEj4gAlTd4hh-CTazpzwBbZ5CbEONG0OIaLvU-HceWs=.460d6385-835e-4908-ba47-2c7183a0144a@github.com>

On Wed, 1 May 2024 14:14:22 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
> 
>   Only change the ProblemList, no risk.

test/hotspot/jtreg/ProblemList.txt line 137:

> 135: serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java 8318090,8318729 generic-all
> 136: serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java 8286836 generic-all
> 137: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64,aix-ppc64,macosx-aarch64

I think it's time to just make this generic-all. We have seen it fail on macosx-x64, and it has already been problem listed for macosx-x64 on 8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19033#discussion_r1592854027

From cjplummer at openjdk.org  Tue May  7 18:53:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 18:53:23 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - Fix jcheck extra whitespace.
 - Fix comment typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/c782279b..049d3884

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

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

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

From cjplummer at openjdk.org  Tue May  7 18:56:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 18:56:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
Message-ID: <9kxb-BEbxmIjxykz-tEOVoGFVovZLhHkvfIj8XmuczU=.14c134f7-234f-4df2-b288-ed5527a176a2@github.com>

On Tue, 7 May 2024 18:53:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix jcheck extra whitespace.
>  - Fix comment typo.

What do you think about the terminology usage of "rank". In this PR the term "higher ranked" means that it must be entered first (before any monitor with a lower rank), but 0 is the highest rank, and bigger numbers mean a lower rank. Sometimes when we rank things (in general) we say #1 is the best, but sometimes we instead rank with a score, and the highest score is the best. I'm wondering if for this PR the rank ordering should be reversed, so a "higher rank" is actually a higher number.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2099099957

From darcy at openjdk.org  Tue May  7 20:07:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 20:07:51 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <kmTopgOeZ_Yf6eiPc0Gh7oM0LZ6oHcVqOSN8SCzNCjI=.5eab6555-7e8b-4a52-a640-6cc161284a60@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by darcy (Reviewer).

> This PR is standalone as opposed to dependent because the #18787 dependency currently has a merge conflict, which complicates the required workflow.
> 
> This comment serves as a reminder to merge master into this PR once #18787 has been integrated. If we don't do that, Skara will likely create a backport issue:
> 
> > (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

Thanks @pavelrappo. For as a small risk-reduction exercise, the fixVersion on the bug could also be changed to tbd, but if it is integrated after the main start-of-release PR it should be fine.

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044060259
PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099210018

From cjplummer at openjdk.org  Tue May  7 21:41:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 May 2024 21:41:54 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v2]
In-Reply-To: <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
 <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>
Message-ID: <hJqYjPDvnGWdNYTgOe87MmQLoobvTQyYvE7hMzuAk30=.b85d27ca-dc6b-464b-a976-4c1c0b61ba05@github.com>

On Tue, 7 May 2024 16:38:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
>> 
>> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris comments and cleanup

SA changes look good. Thanks for taking care of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19107#pullrequestreview-2044246122

From prappo at openjdk.org  Tue May  7 22:10:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 22:10:53 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <Ax3HA7Cn9cS7l4Sq6zx7hKROScWxfaxstyVbYYjwsjk=.2dbd81da-e52b-4fa6-96ad-806e6f8da96e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Thanks for reviewing it Joe, I'm now delegating integration of this PR to @JesperIRL, you, or anyone who will be integrating https://github.com/openjdk/jdk/pull/18787.

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099395990

From jjg at openjdk.org  Tue May  7 22:49:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 May 2024 22:49:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <I2vdyKRyeXvT4eh5stuey2iikuERgf0FaTWcLH0zfkU=.e5752386-61d8-4479-a554-1be2192baa8b@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044314419

From syan at openjdk.org  Wed May  8 01:19:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 8 May 2024 01:19:05 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
Message-ID: <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>

> Hi,
>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
> 
>   Only change the ProblemList, no risk.

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

  problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19033/files
  - new: https://git.openjdk.org/jdk/pull/19033/files/16aa527b..fc1ef659

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

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

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

From syan at openjdk.org  Wed May  8 01:19:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 8 May 2024 01:19:06 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <mEj4gAlTd4hh-CTazpzwBbZ5CbEONG0OIaLvU-HceWs=.460d6385-835e-4908-ba47-2c7183a0144a@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <mEj4gAlTd4hh-CTazpzwBbZ5CbEONG0OIaLvU-HceWs=.460d6385-835e-4908-ba47-2c7183a0144a@github.com>
Message-ID: <40LMGV6OhwHexuWxyK2oZbEas-9M0KRYZ6mTXjC3RrY=.48e4b054-a66a-46e3-8bd6-eb07bf4fdc05@github.com>

On Tue, 7 May 2024 17:43:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
>
> test/hotspot/jtreg/ProblemList.txt line 137:
> 
>> 135: serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java 8318090,8318729 generic-all
>> 136: serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java 8286836 generic-all
>> 137: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64,aix-ppc64,macosx-aarch64
> 
> I think it's time to just make this generic-all. We have seen it fail on macosx-x64, and it has already been problem listed for macosx-x64 on 8.

Thanks for the review. The review has been modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19033#discussion_r1593261927

From sspitsyn at openjdk.org  Wed May  8 07:40:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 07:40:53 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
Message-ID: <hkO7iq_UmUWRT8sA8tTJu5SohwLfYqiNVAAhWYef_xE=.87d06d7b-5a3e-40de-86b6-cb93d8f19842@github.com>

On Wed, 8 May 2024 01:19:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
>> 
>>   Only change the ProblemList, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19033#pullrequestreview-2044866363

From sspitsyn at openjdk.org  Wed May  8 08:08:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 08:08:55 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v3]
In-Reply-To: <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
Message-ID: <xJwEhM3vvALhmuRfX4u3XwB0oQLrUVShFQTJeu_Mmy0=.575aa4b4-d477-4883-978b-e0fb26a5ce33@github.com>

On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review - DaemonThreadTest.java, no need for checking if thread is virtual

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19016#pullrequestreview-2044949004

From mbaesken at openjdk.org  Wed May  8 08:13:57 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 May 2024 08:13:57 GMT
Subject: RFR: 8327769: jcmd GC.heap_dump without options should write to
 location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <QS3QyzDYipWsZwDszTrKQA4oDe0ouaVb8A4TxVIsLyE=.8ab73095-d74e-4c93-89f9-20194419aed8@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

Another option would be to implement an additional jcmd command where  jcmd GC.heap_dump_other_command_name  without options writes to location given by -XX:HeapDumpPath, if set.  This would avoid all the compatibility concerns raised by changing  jcmd GC.heap_dump;  would this be a welcome change ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2100000731

From ayang at openjdk.org  Wed May  8 10:04:15 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 May 2024 10:04:15 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v5]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <3KivzgORzLhAreonPr-CJki3nXgPznlKMpqI4fQCWuk=.f44a8b19-56e6-4809-ac7b-659d700407af@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into s1-do-collect
 - merge
 - review
 - Merge branch 'master' into s1-do-collect
 - s1-do-collect

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

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=04
  Stats: 566 lines in 15 files changed: 125 ins; 356 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From jpai at openjdk.org  Wed May  8 10:13:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 10:13:58 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v3]
In-Reply-To: <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <XIrsDm3I-vSLvsIk0c56n2YSCXPLuvHq_r_63-Au20s=.b51c1a31-ec49-4207-b7f3-5333c4347916@github.com>
Message-ID: <VTxxZuf4_u_GIOBH9A4pgW59FaJQ37-nnPHOG-sgvtc=.59060b47-6d91-4e0d-af2d-39b441625da6@github.com>

On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review - DaemonThreadTest.java, no need for checking if thread is virtual

Thank you Chris and Serguei for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/19016#issuecomment-2100231199

From jpai at openjdk.org  Wed May  8 10:13:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 10:13:59 GMT
Subject: Integrated: 8308033: The jcmd thread dump related tests should test
 virtual threads
In-Reply-To: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
Message-ID: <BKdZdNFTPmtRzihOuPXWpgvwZlcqFtV15NxB0vrH8co=.c290ddd2-bbf2-4da8-850f-1edc494cf4cb@github.com>

On Tue, 30 Apr 2024 09:54:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
> 
> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
> 
> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
> 
> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
> 
> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

This pull request has now been integrated.

Changeset: edd47c10
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edd47c10ebfdc021368820dec6a109251554e8b0
Stats:     63 lines in 6 files changed: 47 ins; 7 del; 9 mod

8308033: The jcmd thread dump related tests should test virtual threads

Reviewed-by: cjplummer, sspitsyn

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

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

From syan at openjdk.org  Wed May  8 12:10:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 8 May 2024 12:10:56 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <hkO7iq_UmUWRT8sA8tTJu5SohwLfYqiNVAAhWYef_xE=.87d06d7b-5a3e-40de-86b6-cb93d8f19842@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
 <hkO7iq_UmUWRT8sA8tTJu5SohwLfYqiNVAAhWYef_xE=.87d06d7b-5a3e-40de-86b6-cb93d8f19842@github.com>
Message-ID: <LpzxvhJ0c_GUMypa64t7Y1bjjqH7p1yS_xGGJdg4VPU=.eae2d0a3-d1b8-49de-94d1-adc4b4f37a58@github.com>

On Wed, 8 May 2024 07:37:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
>
> Marked as reviewed by sspitsyn (Reviewer).

@sspitsyn Thanks for the approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2100431846

From sspitsyn at openjdk.org  Wed May  8 15:32:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 15:32:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <9kxb-BEbxmIjxykz-tEOVoGFVovZLhHkvfIj8XmuczU=.14c134f7-234f-4df2-b288-ed5527a176a2@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <9kxb-BEbxmIjxykz-tEOVoGFVovZLhHkvfIj8XmuczU=.14c134f7-234f-4df2-b288-ed5527a176a2@github.com>
Message-ID: <N6xeJFeW8szqN-XCuynfUIsjWbyLaHMVzkkjNfHjLHw=.5bec84e9-e963-4a56-8401-2950f68a28fa@github.com>

On Tue, 7 May 2024 18:54:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> What do you think about the terminology usage of "rank". 

I slightly prefer to have the same rank order as Hotspot uses.
At the same time, I'm not sure if it won't cause any issues/difficulties. But I'd give it a try.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2100849353

From cjplummer at openjdk.org  Wed May  8 16:41:56 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 16:41:56 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
Message-ID: <ibh25Y2w6yBZQM3Y41pJK-hZsj5pfl_SDzaErloYKlg=.bbc66d78-bf5e-4a95-9002-50bb4fd35ed9@github.com>

On Wed, 8 May 2024 01:19:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
>> 
>>   Only change the ProblemList, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19033#pullrequestreview-2046145463

From sspitsyn at openjdk.org  Wed May  8 16:52:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 16:52:56 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
Message-ID: <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>

On Tue, 7 May 2024 18:53:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix jcheck extra whitespace.
>  - Fix comment typo.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 66:

> 64: debugLoop_initialize(void)
> 65: {
> 66:     vmDeathLock = debugMonitorCreate(vmDeathLockForDebugLoop_Rank, "JDWP VM_DEATH Lock");

Nit: Just a suggestion to consider...
Can all the `debugMonitor's` created by one function `debugMonitor_initialize()` called by initialize() at start .  Then each monitor consumer can cache needed `debugMonitor's` like this:

vmDeathLock = getDebugMonitor(vmDeathLockForDebugLoop_Rank);

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1117:

> 1115:     jrawMonitorID monitor;
> 1116:     const char* name;
> 1117:     DebugRawMonitorRank rank;

Nit: Please, consider to add same comment for lines #1116-1117 as for the line #1119 below.
It might be useful to move the field `ownerThread` before the other fields (not sure about the `monitor` field), so the same comment can be shared by multiple fields.

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1297:

> 1295:     // We must hold the dbgRawMonitor when calling verifyMonitorRank()
> 1296: 
> 1297:     // Iterate over all the monitors and makes sure we don't already hold one that

Nit: Typo: "makes sure" => "make sure".

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1343:

> 1341:         }
> 1342:     }
> 1343: }

Nit: I'd suggest to consider two separate loops instead of one, something like below:


static void
assertOrderFailure(jthread thread,  DebugRawMonitorRank rank, DebugRawMonitor* dbg_monitor, char* msg)
{
    char* threadName = getThreadName(thread);
     tty_message("DebugRawMonitor %s failure: (%s: %d > %d) for thread (%s)",
                 msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);
     jvmtiDeallocate(threadName);
     JDI_ASSERT(JNI_FALSE);
}

static void
verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread thread)
{
    DebugRawMonitorRank i;

    // 1. Verify the held monitor's rank is lower than the rank of the monitor we are trying to enter.
    for (i = rank + 1; i < FIRST_LEAF_DEBUG_RAW_MONITOR; i++) {
        DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
        if (dbg_monitor->ownerThread != NULL &&
            isSameObject(env, dbg_monitor->ownerThread, thread)) {
            // the lower ranked monitor is already owned by this thread
            assertOrderFailure(thread, rank, dbg_monitor, "RANK ORDER");
        }
    }
    // 2. Verify there are no other leaf monitors owned but this thread.
    for (i = FIRST_LEAF_DEBUG_RAW_MONITOR; i < NUM_DEBUG_RAW_MONITORS; i++) {
        DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
        if (i != rank && isSameObject(env, dbg_monitor->ownerThread, thread)) {
            // the leaf ranked monitor is already owned by this thread
            assertOrderFailure(thread, rank, dbg_monitor, "LEAF RANK");
        }
    }

I hope, this can be tweaked to adopt the `popFrame` locks correction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594254039
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594328246
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594257313
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594285396

From cjplummer at openjdk.org  Wed May  8 18:29:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 18:29:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
Message-ID: <JKJwA16GscvmsVMI9muar8Eg5u9UxHy8H171kx_kuEc=.def00aa1-13bf-4a08-9ead-c2c283ecbed4@github.com>

On Wed, 8 May 2024 15:44:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix jcheck extra whitespace.
>>  - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 66:
> 
>> 64: debugLoop_initialize(void)
>> 65: {
>> 66:     vmDeathLock = debugMonitorCreate(vmDeathLockForDebugLoop_Rank, "JDWP VM_DEATH Lock");
> 
> Nit: Just a suggestion to consider (there was a similar suggestion from by Alex)...
> Can all the `debugMonitor's` created/initialized by one function `debugMonitor_initialize()` called by util_initialize()?  Then each monitor consumer can cache needed `debugMonitor's` like this:
> 
> vmDeathLock = getDebugMonitor(vmDeathLockForDebugLoop_Rank);

I think you are suggesting that all monitors be created up front during util_intialize(). The debug agent in the past has always created them lazily (and sometimes some of them end up never being created because they are not needed). I don't really see a big advantage in creating them all up front.

Alex's suggestion was a very different one, and was just a suggestion to initialize all the DebugRawMonitor ranks up front rather than when the jMonitorID is created, and the reason for the suggestion was to avoid having to grab the dbgRawMonitor when setting the rank, but I wasn't convinced that it actually allowed you to not grab the dbgRawMonitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594466821

From cjplummer at openjdk.org  Wed May  8 18:47:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 18:47:55 GMT
Subject: RFR: 8327769: jcmd GC.heap_dump without options should write to
 location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <nHsGCZY7cWaYDWQMIHHeG1-b6aDGgAz0U0wpIJ40i_o=.6e3dd7f7-3c5e-4dbb-b3fd-671a994121d8@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

That might be acceptable, although coming up with a good name will be a challenge.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2101213868

From cjplummer at openjdk.org  Wed May  8 19:11:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 19:11:55 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
Message-ID: <qN5j8zoqc-tUmkr-1bydpH0vTqbDR7qMVR2Knz5VDKc=.e6d08059-93f5-4052-98f9-36e6d705e6ac@github.com>

On Wed, 8 May 2024 16:46:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix jcheck extra whitespace.
>>  - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1117:
> 
>> 1115:     jrawMonitorID monitor;
>> 1116:     const char* name;
>> 1117:     DebugRawMonitorRank rank;
> 
> Nit: Please, consider to add same comment for lines #1116-1117 as for the line #1119 below.
> It might be useful to move the field `ownerThread` before the other fields (not sure about the `monitor` field), so the same comment can be shared by multiple fields.

I kind of don't want to distract from the point that ownerThread is protected by the dbgRawMonitor, and that is the main purpose of dbgRawMonitor. Once you have verified that ownerThread is the current thread, you can release the dbgRawMonitor and access the rank and name fields safely.

There is a race issue with all the fields during debugMonitorCreate() and verifyMonitorRank(), which is why the debugMonitorCreate() must hold the dbgRawMonitor(). However, there is not a race with the fields (other than ownerThread) for the DebugRawMonitor passed into the debugMonitorXXX() APIs because they are not called until the DebugRawMonitor is done being initialized. So this means that debugMonitorXXX() can access the monitor, name, and rank fields without holding dbgRawMonitor, because they are guaranteed to be fully initialized by that point, and they don't change. ownerThread does change, so you must access it while holding the dbgRawMonitor. Technically speaking entryCount could also be changed by other threads, but we don't access it until we know the current thread owns the DebugRawMonitor, so it is safe to access (no other thread would modify or access it).

To put this another way, the debugMonitorXXX() APIs can safely access most of the DebugRawMonitor fields for the DebugRawMonitor passed in because we know they are initialized by this point and don't change. ownerThread (and to some extent entryCount) are the exception. verifyMonitorRank() introduces additional synchronization issues because it iterates over all DebugRawMonitors, and some might be in the middle of creation, so some synchronization with the creation code is needed.

However, I now realize that if we initialized all the monitors up front, then there would be no need to hold dbgRawMonitor during debugMonitorCreate(), although this does not allow for any improvements in verifyMonitorRank() because it still needs to hold the  dbgRawMonitor due to accessing the ownerThread field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594512889

From cjplummer at openjdk.org  Wed May  8 19:27:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 19:27:09 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v5]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <_NhoqUEYJlOpodENubBf1nC1ftY4pA_Fa8waU17nQsY=.000d62d8-b76d-426e-8462-d20fd9e8be5d@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix minor comment typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/049d3884..301da7d5

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

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

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

From cjplummer at openjdk.org  Wed May  8 19:27:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 19:27:10 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
Message-ID: <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>

On Wed, 8 May 2024 15:47:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix jcheck extra whitespace.
>>  - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1297:
> 
>> 1295:     // We must hold the dbgRawMonitor when calling verifyMonitorRank()
>> 1296: 
>> 1297:     // Iterate over all the monitors and makes sure we don't already hold one that
> 
> Nit: Typo: "makes sure" => "make sure".

Fixed.

> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1343:
> 
>> 1341:         }
>> 1342:     }
>> 1343: }
> 
> Nit: I'd suggest to consider two separate loops instead of one, something like below:
> 
> 
> static void
> assertOrderFailure(jthread thread,  DebugRawMonitorRank rank, DebugRawMonitor* dbg_monitor, char* msg)
> {
>     char* threadName = getThreadName(thread);
>      tty_message("DebugRawMonitor %s failure: (%s: %d > %d) for thread (%s)",
>                  msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);
>      jvmtiDeallocate(threadName);
>      JDI_ASSERT(JNI_FALSE);
> }
> 
> static void
> verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread thread)
> {
>     DebugRawMonitorRank i;
> 
>     // 1. Verify the held monitor's rank is lower than the rank of the monitor we are trying to enter.
>     for (i = rank + 1; i < FIRST_LEAF_DEBUG_RAW_MONITOR; i++) {
>         DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
>         if (dbg_monitor->ownerThread != NULL &&
>             isSameObject(env, dbg_monitor->ownerThread, thread)) {
>             // the lower ranked monitor is already owned by this thread
>             assertOrderFailure(thread, rank, dbg_monitor, "RANK ORDER");
>         }
>     }
>     // 2. Verify there are no other leaf monitors owned but this thread.
>     for (i = FIRST_LEAF_DEBUG_RAW_MONITOR; i < NUM_DEBUG_RAW_MONITORS; i++) {
>         DebugRawMonitor* dbg_monitor = &dbg_monitors[i];
>         if (i != rank && isSameObject(env, dbg_monitor->ownerThread, thread)) {
>             // the leaf ranked monitor is already owned by this thread
>             assertOrderFailure(thread, rank, dbg_monitor, "LEAF RANK");
>         }
>     }
> 
> I hope, this can be tweaked to adopt the `popFrame` locks correction.

The special popFrame check needs to go in the first loop only, so it shouldn't be a problem or add any complexity that we don't already have.

One things to resolve is if we enter a regular monitor while holding a leaf monitor, is this a "rank" failure or "leaf" failure. Currently in the code it is a "rank" failure. Your change would make it a "leaf" failure.

I'm not sure why you added the "i != rank" check with the leaf check. We should never be re-entering a leaf monitor. The same "dbg_monitor->ownerThread != NULL" check as in the first loop should be used.

assertOrderFailure() won't be able to print as descriptive of a message as what I currently have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594526975
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594525608

From sspitsyn at openjdk.org  Wed May  8 20:12:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 20:12:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <JKJwA16GscvmsVMI9muar8Eg5u9UxHy8H171kx_kuEc=.def00aa1-13bf-4a08-9ead-c2c283ecbed4@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <JKJwA16GscvmsVMI9muar8Eg5u9UxHy8H171kx_kuEc=.def00aa1-13bf-4a08-9ead-c2c283ecbed4@github.com>
Message-ID: <w8h9kLfhp_IJoHhKMvwFx0PBBzLkf-i_18iAGSqi4Qc=.0863b787-c9f5-4518-8b34-2997ae2db9c9@github.com>

On Wed, 8 May 2024 18:27:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 66:
>> 
>>> 64: debugLoop_initialize(void)
>>> 65: {
>>> 66:     vmDeathLock = debugMonitorCreate(vmDeathLockForDebugLoop_Rank, "JDWP VM_DEATH Lock");
>> 
>> Nit: Just a suggestion to consider (there was a similar suggestion from by Alex)...
>> Can all the `debugMonitor's` created/initialized by one function `debugMonitor_initialize()` called by util_initialize()?  Then each monitor consumer can cache needed `debugMonitor's` like this:
>> 
>> vmDeathLock = getDebugMonitor(vmDeathLockForDebugLoop_Rank);
>
> I think you are suggesting that all monitors be created up front during util_intialize(). The debug agent in the past has always created them lazily (and sometimes some of them end up never being created because they are not needed). I don't really see a big advantage in creating them all up front.
> 
> Alex's suggestion was a very different one, and was just a suggestion to initialize all the DebugRawMonitor ranks up front rather than when the jMonitorID is created, and the reason for the suggestion was to avoid having to grab the dbgRawMonitor when setting the rank, but I wasn't convinced that it actually allowed you to not grab the dbgRawMonitor.

I just wanted to say that Alex's suggestion is in a similar direction.
I do not see a big advantage to save just on creation of a few monitors. It is not a scalability problem as their number is constant. Creation of the monitors at initialization time is a simplification as we do not care about synchronization at this phase. Also, it is easier to understand because there is no interaction with other threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594571559

From sspitsyn at openjdk.org  Wed May  8 20:26:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 20:26:00 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
Message-ID: <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>

On Wed, 8 May 2024 19:22:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The special popFrame check needs to go in the first loop only, so it shouldn't be a problem or add any complexity that we don't already have.

Sounds good.

> One things to resolve is if we enter a regular monitor while holding a leaf monitor, is this a "rank" failure or "leaf" failure. Currently in the code it is a "rank" failure. Your change would make it a "leaf" failure.

A "leaf" failure is more specific than a "rank order" failure, so it is better to report it first. Each "leaf" failure is also  a "rank order" failure (AFAICS).

> I'm not sure why you added the "i != rank" check with the leaf check. We should never be re-entering a leaf monitor. The same "dbg_monitor->ownerThread != NULL" check as in the first loop should be used.

You are right. This check is not needed and has to be removed. I was thinking a leaf monitor can be grabbed recursively.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594583974

From sspitsyn at openjdk.org  Wed May  8 20:28:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 20:28:55 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <qN5j8zoqc-tUmkr-1bydpH0vTqbDR7qMVR2Knz5VDKc=.e6d08059-93f5-4052-98f9-36e6d705e6ac@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <qN5j8zoqc-tUmkr-1bydpH0vTqbDR7qMVR2Knz5VDKc=.e6d08059-93f5-4052-98f9-36e6d705e6ac@github.com>
Message-ID: <z40u0iA2Kp_wbxMj4mDQ4tRfqVUDOsYToNI4H1kkHTw=.0633424b-5af9-4081-bd88-14305702853d@github.com>

On Wed, 8 May 2024 19:09:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1117:
>> 
>>> 1115:     jrawMonitorID monitor;
>>> 1116:     const char* name;
>>> 1117:     DebugRawMonitorRank rank;
>> 
>> Nit: Please, consider to add same comment for lines #1116-1117 as for the line #1119 below.
>> It might be useful to move the field `ownerThread` before the other fields (not sure about the `monitor` field), so the same comment can be shared by multiple fields.
>
> I kind of don't want to distract from the point that ownerThread is protected by the dbgRawMonitor, and that is the main purpose of dbgRawMonitor. Once you have verified that ownerThread is the current thread, you can release the dbgRawMonitor and access the rank and name fields safely.
> 
> There is a race issue with all the fields during debugMonitorCreate() and verifyMonitorRank(), which is why the debugMonitorCreate() must hold the dbgRawMonitor(). However, there is not a race with the fields (other than ownerThread) for the DebugRawMonitor passed into the debugMonitorXXX() APIs because they are not called until the DebugRawMonitor is done being initialized. So this means that debugMonitorXXX() can access the monitor, name, and rank fields without holding dbgRawMonitor, because they are guaranteed to be fully initialized by that point, and they don't change. ownerThread does change, so you must access it while holding the dbgRawMonitor. Technically speaking entryCount could also be changed by other threads, but we don't access it until we know the current thread owns the DebugRawMonitor, so it is safe to access (no other thread would modify or access it).
> 
> To put this another way, the debugMonitorXXX() APIs can safely access most of the DebugRawMonitor fields for the DebugRawMonitor passed in because we know they are initialized by this point and don't change. ownerThread (and to some extent entryCount) are the exception. verifyMonitorRank() introduces additional synchronization issues because it iterates over all DebugRawMonitors, and some might be in the middle of creation, so some synchronization with the creation code is needed.
> 
> However, I now realize that if we initialized all the monitors up front, then there would be no need to hold dbgRawMonitor during debugMonitorCreate(), although this does not allow for any improvements in verifyMonitorRank() because it still needs to hold the  dbgRawMonitor due to accessing the ownerThread field.

No pressure, it is up to you. I just wonder if there is any room to make it a little bit more clear and simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594587018

From cjplummer at openjdk.org  Wed May  8 20:36:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 20:36:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
Message-ID: <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>

On Wed, 8 May 2024 20:23:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A "leaf" failure is more specific than a "rank order" failure, so it is better to report it first. Each "leaf" failure is also a "rank order" failure (AFAICS).

It's not just a matter of which is reported first. Even if you swap the order of your two loops you get the same result. The problem is the "rank" loop does not check if any of the leaf monitors are already held. I think to fix that it would have to iterate up to NUM_DEBUG_RAW_MONITORS, which means there is overlap with the range that the "leaf" loop iterators over.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594593936

From sspitsyn at openjdk.org  Wed May  8 21:47:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 21:47:55 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
Message-ID: <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>

On Wed, 8 May 2024 20:34:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> The special popFrame check needs to go in the first loop only, so it shouldn't be a problem or add any complexity that we don't already have.
>> 
>> Sounds good.
>> 
>>> One things to resolve is if we enter a regular monitor while holding a leaf monitor, is this a "rank" failure or "leaf" failure. Currently in the code it is a "rank" failure. Your change would make it a "leaf" failure.
>> 
>> A "leaf" failure is more specific than a "rank order" failure, so it is better to report it first. Each "leaf" failure is also  a "rank order" failure (AFAICS).
>> 
>>> I'm not sure why you added the "i != rank" check with the leaf check. We should never be re-entering a leaf monitor. The same "dbg_monitor->ownerThread != NULL" check as in the first loop should be used.
>> 
>> You are right. This check is not needed and has to be removed. I was thinking a leaf monitor can be grabbed recursively.
>
>> A "leaf" failure is more specific than a "rank order" failure, so it is better to report it first. Each "leaf" failure is also a "rank order" failure (AFAICS).
> 
> It's not just a matter of which is reported first. Even if you swap the order of your two loops you get the same result. The problem is the "rank" loop does not check if any of the leaf monitors are already held. I think to fix that it would have to iterate up to NUM_DEBUG_RAW_MONITORS, which means there is overlap with the range that the "leaf" loop iterators over.

In fact, I do not understand why reporting the "rank order" violation is important what "leaf rank order" is violated. I feel that I'm missing something. Let me think on it a little bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594725455

From cjplummer at openjdk.org  Wed May  8 22:12:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 22:12:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
Message-ID: <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>

On Wed, 8 May 2024 21:44:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> A "leaf" failure is more specific than a "rank order" failure, so it is better to report it first. Each "leaf" failure is also a "rank order" failure (AFAICS).
>> 
>> It's not just a matter of which is reported first. Even if you swap the order of your two loops you get the same result. The problem is the "rank" loop does not check if any of the leaf monitors are already held. I think to fix that it would have to iterate up to NUM_DEBUG_RAW_MONITORS, which means there is overlap with the range that the "leaf" loop iterators over.
>
> In fact, I do not understand why reporting the "rank order" violation is important what "leaf rank order" is violated. I feel that I'm missing something. Let me think on it a little bit.

If the following are all true 
- you are entering is a leaf monitor
- the current thread has already entered a leaf monitor
- the rank of the monitor you are entering is lower than the rank of the monitor already held

Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. My current implementation will complain about the rank violation (although can easily be made to instead complain about the leaf violation or complain about both). Yours will complain about the leaf violation.  To make yours instead complain about the rank violation, the first loop needs to also check all the leaf monitors. Since the 2nd loop also checks all the leaf monitors (but for a different reason), this means iterating over the leaf monitors twice. Complaining about both violations would also require iterating over the leaf monitors twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594757398

From larry.cable at oracle.com  Wed May  8 22:16:01 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 8 May 2024 15:16:01 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container)
In-Reply-To: <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com>
Message-ID: <776f0c06-c2f4-495d-93a3-dad61f259f76@oracle.com>



On 5/3/24 10:43 AM, jdoylei wrote:
> On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:
>
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>> I think it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.
> @slovdahl - In that test case (target JVM process has more privileges), where is the attach file created?  Does jcmd end up writing it to `/tmp`?  Or does `/proc/<pid>/cwd` work?  Just curious whether the elevated-privileges scenario affects the attach file and socket file locations equally.

note that the use of 'cwd' is a historical artifact, while the 
.attach_<pid> file can be written to 'cwd' the actual attach socket file 
.java_<pid> is always written to /tmp
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2093481534


From larry.cable at oracle.com  Wed May  8 22:16:11 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 8 May 2024 15:16:11 -0700
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid
 == ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
 <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com>
Message-ID: <d193d9a9-a6e0-409b-913c-d6561dde1543@oracle.com>


I did some thinking on this issue over the weekend and came up with an 
idea that *may* improve the probability of an attach succeeding in the
case that the target has elevated privileges and the jcmd is not in the 
same mnt namespace as the target JVM.

basically, the idea is to recurse "up"the process hierarchy from the 
target JVM process looking for either occupancy of the same mnt namespace
(meaning that using /tmp to rendezvous on the attach socket will 
succeed) or in the case where the target JVM process has elevated privileges
and thus the jcmd cannot determine if it shares a mnt ns, or cannot 
read/write the /proc/<target_pid>/root/tmp directory.

In this case, the attach code walks "up" the process hierarchy looking 
for the closest ancestor of the target JVM that either occupies the same
mnt ns, or with a r/w /proc/<ancestor_pid>/root/tmp

since the JVM does not manipulate its pid nor mnt ns'es or modify it's 
(linux) capabilities, if such has occurred then it was caused by an ancestor
process of the target (in the case of a container this is most likely 
the container manager or a delegate thereof.

should the jcmd find either an ancestor in the same mnt ns (/tmp) or a 
r/w /proc/<ancestor_pid>/root/tmp it will return that path as the directory
in which to rendezvous with the target JVM.

this approach "increases the odds" that the jcmd will successfully 
attach to a containerized and/or elevated privilege JVM.

needless to say this is "experimental" and needs proper stress testing 
for the appropriate use cases.

Rgds

- Larry

-------------- next part --------------
diff --git a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
index 81d4fd259ed..050d8bbb2a9 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -34,6 +34,7 @@
 import java.nio.file.Path;
 import java.nio.file.Paths;
 import java.nio.file.Files;
+import java.util.Optional;
 
 import static java.nio.charset.StandardCharsets.UTF_8;
 
@@ -46,13 +47,45 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
     // location is the same for all processes, otherwise the tools
     // will not be able to find all Hotspot processes.
     // Any changes to this needs to be synchronized with HotSpot.
-    private static final String tmpdir = "/tmp";
+    private static final Path TMPDIR = Path.of("/tmp");
+
+    private static final Path PROC     = Path.of("/proc");
+    private static final Path NS_MNT   = Path.of("ns/mnt");
+    private static final Path NS_PID   = Path.of("ns/pid");
+    private static final Path SELF     = PROC.resolve("self");
+    private static final Path TMP      = Path.of("tmp");
+    private static final Path STATUS   = Path.of("status");
+    private static final Path ROOT_TMP = Path.of("root/tmp");
+
+    private static final Optional<Path> SELF_MNT_NS;
+    private static final Optional<Path> SELF_PID_NS;
+
+    static {
+        Path nsPath = null;
+
+        try {
+            nsPath = Files.readSymbolicLink(SELF.resolve(NS_MNT));
+        } catch (IOException _) {
+	    // do nothing
+        } finally {
+            SELF_MNT_NS = Optional.ofNullable(nsPath);
+        }
+
+        try {
+            nsPath = Files.readSymbolicLink(SELF.resolve(NS_PID));
+        } catch (IOException _) {
+            // do nothing
+        } finally {
+            SELF_PID_NS = Optional.ofNullable(nsPath);
+        }
+    }
+
     String socket_path;
+
     /**
      * Attaches to the target VM
      */
-    VirtualMachineImpl(AttachProvider provider, String vmid)
-        throws AttachNotSupportedException, IOException
+    VirtualMachineImpl(AttachProvider provider, String vmid) throws AttachNotSupportedException, IOException
     {
         super(provider, vmid);
 
@@ -63,12 +96,12 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
         }
 
         // Try to resolve to the "inner most" pid namespace
-        int ns_pid = getNamespacePid(pid);
+        final long ns_pid = getNamespacePid(pid);
 
         // Find the socket file. If not found then we attempt to start the
         // attach mechanism in the target VM by sending it a QUIT signal.
         // Then we attempt to find the socket file again.
-        File socket_file = findSocketFile(pid, ns_pid);
+        final File socket_file = findSocketFile(pid, ns_pid);
         socket_path = socket_file.getPath();
         if (!socket_file.exists()) {
             // Keep canonical version of File, to delete, in case target process ends and /proc link has gone:
@@ -210,49 +243,95 @@ protected void close(long fd) throws IOException {
     }
 
     // Return the socket file for the given process.
-    private File findSocketFile(int pid, int ns_pid) throws IOException {
-        String root = findTargetProcessTmpDirectory(pid, ns_pid);
-        return new File(root, ".java_pid" + ns_pid);
+    private File findSocketFile(long pid, long ns_pid) throws AttachNotSupportedException, IOException {
+        return new File(findTargetProcessTmpDirectory(pid, ns_pid), ".java_pid" + ns_pid);
     }
 
     // On Linux a simple handshake is used to start the attach mechanism
     // if not already started. The client creates a .attach_pid<pid> file in the
     // target VM's working directory (or temp directory), and the SIGQUIT handler
     // checks for the file.
-    private File createAttachFile(int pid, int ns_pid) throws IOException {
-        String fn = ".attach_pid" + ns_pid;
-        String path = "/proc/" + pid + "/cwd/" + fn;
-        File f = new File(path);
+    private File createAttachFile(long pid, long ns_pid) throws AttachNotSupportedException, IOException {
+        Path fn   = Path.of(".attach_pid" + ns_pid);
+        Path path = PROC.resolve(Path.of(Long.toString(pid), "cwd")).resolve(fn);
+        File f    = new File(path.toString());
         try {
             // Do not canonicalize the file path, or we will fail to attach to a VM in a container.
             f.createNewFile();
-        } catch (IOException x) {
-            String root = findTargetProcessTmpDirectory(pid, ns_pid);
-            f = new File(root, fn);
+        } catch (IOException _) {
+            f = new File(findTargetProcessTmpDirectory(pid, ns_pid), fn.toString());
             f.createNewFile();
         }
         return f;
     }
 
-    private String findTargetProcessTmpDirectory(int pid, int ns_pid) throws IOException {
-        String root;
-        if (pid != ns_pid) {
-            // A process may not exist in the same mount namespace as the caller, e.g.
-            // if we are trying to attach to a JVM process inside a container.
-            // Instead, attach relative to the target root filesystem as exposed by
-            // procfs regardless of namespaces.
-            String procRootDirectory = "/proc/" + pid + "/root";
-            if (!Files.isReadable(Path.of(procRootDirectory))) {
-                throw new IOException(
-                        String.format("Unable to access root directory %s " +
-                          "of target process %d", procRootDirectory, pid));
+    private String findTargetProcessTmpDirectory(long pid, long ns_pid) throws AttachNotSupportedException, IOException {
+        Optional<ProcessHandle> tgt = ProcessHandle.of(pid);
+        Optional<ProcessHandle> ph = tgt;
+        long nsPid = ns_pid;
+        Optional<Path> prevPidNS = Optional.empty();
+
+        while (ph.isPresent()) {
+            final var curPid = ph.get().pid();
+
+            final var procPidPath = PROC.resolve(Long.toString(curPid));
+
+            Optional<Path> tgtMountNS = Optional.empty();
+
+            try {
+                tgtMountNS = Optional.ofNullable(Files.readSymbolicLink(procPidPath.resolve(NS_MNT))); // attempt to read the tgt's mnt ns id...
+            } catch (
+                    IOException _) { // if we fail to read the tgt's mnt ns id then we either dont have access or it no longer exists!
+                if (!Files.exists(procPidPath))
+                    throw new IOException(String.format("unable to attach, %s non-existent! process: %d terminated", procPidPath, pid));
+
+                // ok so if we get here we have failed to read the tgt's mnt ns, but the tgt process still exists ... we do not have privs to read its procfs
+            }
+
+            final var sameMountNS = SELF_MNT_NS.isPresent() && SELF_MNT_NS.equals(tgtMountNS); // will be false  if we did not read the tgt's mnt ns
+
+            if (sameMountNS) {
+                return TMPDIR.toString(); // we share TMPDIR in common!
+            } else {
+                final var procPidRootTmp = procPidPath.resolve(ROOT_TMP);
+
+                if (Files.isReadable(procPidRootTmp)) return procPidRootTmp.toString(); // not in the same mnt ns but tmp is accessible via /proc...
+            }
+
+            // lets attempt to obtain the pid NS... best efforts to avoid crossing pid ns boundaries (as with a container)
+
+            Optional<Path> curPidNS = Optional.empty();
+
+            try {
+                curPidNS = Optional.ofNullable(Files.readSymbolicLink(procPidPath.resolve(NS_PID))); // attempt to read the tgt's mnt ns id...
+            } catch (IOException _) { // if we fail to read the tgt's pid ns id then we either dont have access or it no longer exists!
+                if (!Files.exists(procPidPath)) throw new IOException(String.format("unable to attach, %s non-existent! process: %d terminated", procPidPath, pid));
+
+                // ok so if we get here we have failed to read the tgt's pid ns, but the tgt process still exists ... we do not have privs to read its procfs
+            }
+
+            // recurse "up" the process heirarchy... if appropriate
+
+            final var havePidNSes = prevPidNS.isPresent() && curPidNS.isPresent();
+
+            final var ppid = ph.get().parent();
+
+            if (ppid.isPresent() && (havePidNSes && curPidNS.equals(prevPidNS)) || (!havePidNSes && nsPid > 1)) {
+                ph = ppid;
+
+                nsPid = getNamespacePid(ph.get().pid()); // get the ns pid of the parent...
+
+                prevPidNS = curPidNS;
+            } else {
+                ph = Optional.empty();
             }
+        }
 
-            root = procRootDirectory + "/" + tmpdir;
+        if (tgt.orElseThrow(AttachNotSupportedException::new).isAlive()) {
+            return TMPDIR.toString(); // fallback...
         } else {
-            root = tmpdir;
+            throw new IOException(String.format("unable to attach, process: %d terminated", pid));
         }
-        return root;
     }
 
     /*
@@ -272,10 +351,10 @@ private void writeString(int fd, String s) throws IOException {
 
     // Return the inner most namespaced PID if there is one,
     // otherwise return the original PID.
-    private int getNamespacePid(int pid) throws AttachNotSupportedException, IOException {
+    private long getNamespacePid(long pid) throws AttachNotSupportedException, IOException {
         // Assuming a real procfs sits beneath, reading this doesn't block
         // nor will it consume a lot of memory.
-        String statusFile = "/proc/" + pid + "/status";
+        final var statusFile = PROC.resolve(Long.toString(pid)).resolve(STATUS).toString();
         File f = new File(statusFile);
         if (!f.exists()) {
             return pid; // Likely a bad pid, but this is properly handled later.
@@ -291,8 +370,7 @@ private int getNamespacePid(int pid) throws AttachNotSupportedException, IOExcep
                     // The last entry represents the PID the JVM "thinks" it is.
                     // Even in non-namespaced pids these entries should be
                     // valid. You could refer to it as the inner most pid.
-                    int ns_pid = Integer.parseInt(parts[parts.length - 1]);
-                    return ns_pid;
+                    return Long.parseLong(parts[parts.length - 1]);
                 }
             }
             // Old kernels may not have NSpid field (i.e. 3.10).

From iklam at openjdk.org  Wed May  8 22:28:03 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 8 May 2024 22:28:03 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v2]
In-Reply-To: <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
 <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>
Message-ID: <ToX6UhJEAz8Y3mBHWKy11z8D18ocJj75sijIYnl1tVQ=.edbcd496-d168-4fd6-a6a1-1e3c5719e78e@github.com>

On Tue, 7 May 2024 16:38:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
>> 
>> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris comments and cleanup

Looks good. I will suggest making some clean up to improve the readability of the existing code.

src/hotspot/share/cds/archiveUtils.cpp line 325:

> 323:   assert((intptr_t)obj >= 0 || (intptr_t)obj < -100,
> 324:          "hit tag while initializing ptrs.");
> 325:   *p = obj != 0 ? (void*)(SharedBaseAddress + obj) : (void*)obj;

`nullptr` should be used instead of `0`. E.g., `obj != (void*)nullptr`

src/hotspot/share/cds/cppVtables.cpp line 236:

> 234:   if (!soc->reading()) {
> 235:     _vtables_serialized_base = soc->region_top();
> 236:   }

The new `region_top()` API may be confusing with the existing `do_region()` API, which has a completely different meaning for `region`.

I think it's better to rename `do_region()` to


// iterate on the pointers from p[0] through p[num_pointers-1]
SerializeClosure do_ptrs(void** p, int num_pointers);


Also, there's no need to add a new `region_top()` API -- there are already too many functions that deal with a "region" of different types, and you need to wonder what this particular "region" is.

`soc->region_top()` can be replaced with `ArchiveBuilder::current()->current_dump_space()->top()`

Also, in archiveBuilder.hpp, `dump_space` means the same thing as `dump_region`. All of the former should be changed to the latter for uniformity.

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19107#pullrequestreview-2046836828
PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1594750309
PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1594766914

From cjplummer at openjdk.org  Wed May  8 22:43:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 22:43:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <w8h9kLfhp_IJoHhKMvwFx0PBBzLkf-i_18iAGSqi4Qc=.0863b787-c9f5-4518-8b34-2997ae2db9c9@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <JKJwA16GscvmsVMI9muar8Eg5u9UxHy8H171kx_kuEc=.def00aa1-13bf-4a08-9ead-c2c283ecbed4@github.com>
 <w8h9kLfhp_IJoHhKMvwFx0PBBzLkf-i_18iAGSqi4Qc=.0863b787-c9f5-4518-8b34-2997ae2db9c9@github.com>
Message-ID: <aeF4Mb5FyeS-_zwp1x9irEn6jGO3j4WJ8y3Y2lx-n5Q=.706a44b1-ede0-494c-bb8c-2ebacfa0b104@github.com>

On Wed, 8 May 2024 20:10:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I think you are suggesting that all monitors be created up front during util_intialize(). The debug agent in the past has always created them lazily (and sometimes some of them end up never being created because they are not needed). I don't really see a big advantage in creating them all up front.
>> 
>> Alex's suggestion was a very different one, and was just a suggestion to initialize all the DebugRawMonitor ranks up front rather than when the jMonitorID is created, and the reason for the suggestion was to avoid having to grab the dbgRawMonitor when setting the rank, but I wasn't convinced that it actually allowed you to not grab the dbgRawMonitor.
>
> I just wanted to say that Alex's suggestion is in a similar direction.
> I do not see a big advantage to save just on creation of a few monitors. It is not a scalability problem as their number is constant. Creation of the monitors at initialization time is a simplification as we do not care about synchronization at this phase. Also, it is easier to understand because there is no interaction with other threads.

The init code would have to know the name of each monitor since it is no longer being passed in. Something like the following might work:

static DebugRawMonitor dbg_monitors[] = {
  { NULL, "JDWP VM_DEATH Lock",  vmDeathLockForDebugLoop_Rank, NULL, 0 },
  { NULL, "JDWP Callback Block", callbackBlock_Rank, NULL, 0 },
  { NULL, "JDWP Callback Lock",  callbackLock_Rank, NULL, 0 },
  ...
};

And then the init() function can iterate over the array and allocate the monitor for each entry. Note that this array needs to be kept in sync with the DebugRawMonitorRank enum (same entries and in the same order). I can assert during the initialization that the rank field for each entry is equal to its array index and that the array size is NUM_DEBUG_RAW_MONITORS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594777084

From sspitsyn at openjdk.org  Wed May  8 22:43:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 22:43:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
Message-ID: <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>

On Wed, 8 May 2024 22:10:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In fact, I do not understand why reporting the "rank order" violation is important what "leaf rank order" is violated. I feel that I'm missing something. Let me think on it a little bit.
>
> If the following are all true 
> - you are entering is a leaf monitor
> - the current thread has already entered a leaf monitor
> - the rank of the monitor you are entering is lower than the rank of the monitor already held
> 
> Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. My current implementation will complain about the rank violation (although can easily be made to instead complain about the leaf violation or complain about both). Yours will complain about the leaf violation.  To make yours instead complain about the rank violation, the first loop needs to also check all the leaf monitors. Since the 2nd loop also checks all the leaf monitors (but for a different reason), this means iterating over the leaf monitors twice. Complaining about both violations would also require iterating over the leaf monitors twice.

Okay, thanks.
> Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. 

I kind of disagree with the second part of this statement.
My understanding is that the second loop does a little bit different check:
  "Violation for entering ANY monitor when you have already entered a leaf monitor."
Please, note that `rank` can be any rank including those with conditions:

   rank < FIRST_LEAF_DEBUG_RAW_MONITOR
   rank >= FIRST_LEAF_DEBUG_RAW_MONITOR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594776344

From cjplummer at openjdk.org  Wed May  8 22:55:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 May 2024 22:55:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
 <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
Message-ID: <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>

On Wed, 8 May 2024 22:40:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> If the following are all true 
>> - you are entering is a leaf monitor
>> - the current thread has already entered a leaf monitor
>> - the rank of the monitor you are entering is lower than the rank of the monitor already held
>> 
>> Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. My current implementation will complain about the rank violation (although can easily be made to instead complain about the leaf violation or complain about both). Yours will complain about the leaf violation.  To make yours instead complain about the rank violation, the first loop needs to also check all the leaf monitors. Since the 2nd loop also checks all the leaf monitors (but for a different reason), this means iterating over the leaf monitors twice. Complaining about both violations would also require iterating over the leaf monitors twice.
>
> Okay, thanks.
>> Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. 
> 
> I kind of disagree with the second part of this statement.
> My understanding is that the second loop does a little bit different check:
>   "Violation for entering ANY monitor when you have already entered a leaf monitor."
> Please, note that `rank` can be any rank including those with conditions:
> 
>    rank < FIRST_LEAF_DEBUG_RAW_MONITOR
>    rank >= FIRST_LEAF_DEBUG_RAW_MONITOR
> 
> It seems to me that if the second rule (in my edition) is violated then the first rule does not matter.
> It means that the first rule is for both ranks from the range:
> 
>    0 <= rank < FIRST_LEAF_DEBUG_RAW_MONITOR
>  ```

Yes, the 2nd loop is a different check. That's why I said it also checks all the leaf monitors "but for a different reason".  Your two loops do not flag a rank violation if both monitors are leafs, even if grabbed in the wrong order. It only flags the leaf violation. Your two checks will always catch any violation, it just a matter of whether my example (which is both a leaf and a rank violation) is flagged as a leaf violation or a rank violation (or even both could be indicated if we choose). Yours flags it as a leaf violation. My code flags it as a rank violation. Mine could flag both violations without any additional iterations. Your would need to iterate over the leaf monitors twice to detect if there is both a rank and a leaf violation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594784168

From sspitsyn at openjdk.org  Wed May  8 23:50:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 May 2024 23:50:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
 <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
 <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>
Message-ID: <tYmZtUV1qz1lDQLuGYgIKZVaAU9kvioo50_WSR9v4rI=.8fa6cb1f-0f17-4abf-b4d8-1ec46323bf32@github.com>

On Wed, 8 May 2024 22:53:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Okay, thanks.
>>> Then you have both a rank order violation and a violation for entering a leaf monitor when you have already entered a leaf monitor. 
>> 
>> I kind of disagree with the second part of this statement.
>> My understanding is that the second loop does a little bit different check:
>>   "Violation for entering ANY monitor when you have already entered a leaf monitor."
>> Please, note that `rank` can be any rank including those with conditions:
>> 
>>    rank < FIRST_LEAF_DEBUG_RAW_MONITOR
>>    rank >= FIRST_LEAF_DEBUG_RAW_MONITOR
>> 
>> It seems to me that if the second rule (in my edition) is violated then the first rule does not matter.
>> It means that the first rule is for both ranks from the range:
>> 
>>    0 <= rank < FIRST_LEAF_DEBUG_RAW_MONITOR
>>  ```
>
> Yes, the 2nd loop is a different check. That's why I said it also checks all the leaf monitors "but for a different reason".  Your two loops do not flag a rank violation if both monitors are leafs, even if grabbed in the wrong order. It only flags the leaf violation. Your two checks will always catch any violation, it just a matter of whether my example (which is both a leaf and a rank violation) is flagged as a leaf violation or a rank violation (or even both could be indicated if we choose). Yours flags it as a leaf violation. My code flags it as a rank violation. Mine could flag both violations without any additional iterations. Your would need to iterate over the leaf monitors twice to detect if there is both a rank and a leaf violation.

Okay, thanks. Please, let me list the variants with some analysis.
We have 3 variants:
1.  Both monitors are leaf: Entering any monitor while a leaf monitor has been entered is a violation (`LEAF RULE` violation). The order does not matter. Any order is unacceptable.

2. A non-leaf monitor is being entered while a leaf monitor has been entered: This is also a `LEAF RULE` violation. This violation is at the same time always a "RANK ORDER VIOLATION" for the non-leaf monitor. My view is there is no need to report this "RANK ORDER VIOLATION" as it always coexists with the `LEAF RULE` violation for non-leaf monitors. But if you insist on reporting it additionally then it is not a problem to check and report it in the `assertOrderFailure()` function. It has all needed info available for it.

3. A non-leaf monitor is being entered while a non-leaf monitor has been entered: It is a case+report for "RANK ORDER VIOLATION".

There is one more variant:
4. A leaf monitor is being entered while a non-leaf monitor has been entered: It is never a violation, so this variant is excluded from the list above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594814115

From sspitsyn at openjdk.org  Thu May  9 00:08:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 00:08:54 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <aeF4Mb5FyeS-_zwp1x9irEn6jGO3j4WJ8y3Y2lx-n5Q=.706a44b1-ede0-494c-bb8c-2ebacfa0b104@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <JKJwA16GscvmsVMI9muar8Eg5u9UxHy8H171kx_kuEc=.def00aa1-13bf-4a08-9ead-c2c283ecbed4@github.com>
 <w8h9kLfhp_IJoHhKMvwFx0PBBzLkf-i_18iAGSqi4Qc=.0863b787-c9f5-4518-8b34-2997ae2db9c9@github.com>
 <aeF4Mb5FyeS-_zwp1x9irEn6jGO3j4WJ8y3Y2lx-n5Q=.706a44b1-ede0-494c-bb8c-2ebacfa0b104@github.com>
Message-ID: <0Q9BjsrZpbcMR5LIOgbUQ8pVRQXMS8NS6ohxDLfdHys=.457a0cc3-898d-4344-b909-9d717190b8b0@github.com>

On Wed, 8 May 2024 22:41:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I just wanted to say that Alex's suggestion is in a similar direction.
>> I do not see a big advantage to save just on creation of a few monitors. It is not a scalability problem as their number is constant. Creation of the monitors at initialization time is a simplification as we do not care about synchronization at this phase. Also, it is easier to understand because there is no interaction with other threads.
>
> The init code would have to know the name of each monitor since it is no longer being passed in. Something like the following might work:
> 
> static DebugRawMonitor dbg_monitors[] = {
>   { NULL, "JDWP VM_DEATH Lock",  vmDeathLockForDebugLoop_Rank, NULL, 0 },
>   { NULL, "JDWP Callback Block", callbackBlock_Rank, NULL, 0 },
>   { NULL, "JDWP Callback Lock",  callbackLock_Rank, NULL, 0 },
>   ...
> };
> 
> And then the init() function can iterate over the array and allocate the monitor for each entry. Note that this array needs to be kept in sync with the DebugRawMonitorRank enum (same entries and in the same order). I can assert during the initialization that the rank field for each entry is equal to its array index and that the array size is NUM_DEBUG_RAW_MONITORS.

Can we do as below? :

static DebugRawMonitor dbg_monitors[]; // initialized with all zeros by default
. . .
static void
createDebugRawMonitor(DebugRawMonitorRank rank, const char* name) {
    dbg_monitors[rank] = debugMonitorCreate(rank, name);
}

static void
monitors_initialize() {
  createDebugRawMonitor( vmDeathLockForDebugLoop_Rank, "JDWP VM_DEATH Lock");
  createDebugRawMonitor( callbackBlock_Rank, "JDWP Callback Block");
  createDebugRawMonitor( callbackLock_Rank, "JDWP Callback Lock");
  . . .
}

The pair of  functions `createDebugRawMonitor()+debugMonitorCreate()` can be refactored into just one function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594823032

From cjplummer at openjdk.org  Thu May  9 01:04:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 May 2024 01:04:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <tYmZtUV1qz1lDQLuGYgIKZVaAU9kvioo50_WSR9v4rI=.8fa6cb1f-0f17-4abf-b4d8-1ec46323bf32@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
 <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
 <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>
 <tYmZtUV1qz1lDQLuGYgIKZVaAU9kvioo50_
 WSR9v4rI=.8fa6cb1f-0f17-4abf-b4d8-1ec46323bf32@github.com>
Message-ID: <WNWRHYnzL83pF7CMvnhWd-5IQ-q8HhxuZXtA7tCMq8M=.1ea569af-9e37-4b21-bce3-26d798463d25@github.com>

On Wed, 8 May 2024 23:48:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yes, the 2nd loop is a different check. That's why I said it also checks all the leaf monitors "but for a different reason".  Your two loops do not flag a rank violation if both monitors are leafs, even if grabbed in the wrong order. It only flags the leaf violation. Your two checks will always catch any violation, it just a matter of whether my example (which is both a leaf and a rank violation) is flagged as a leaf violation or a rank violation (or even both could be indicated if we choose). Yours flags it as a leaf violation. My code flags it as a rank violation. Mine could flag both violations without any additional iterations. Your would need to iterate over the leaf monitors twice to detect if there is both a rank and a leaf violation.
>
> Okay, thanks. Please, let me list the variants with some analysis.
> We have 3 variants:
> 1.  Both monitors are leaf: Entering any monitor while a leaf monitor has been entered is a violation (`LEAF RULE` violation). The order does not matter. Any order is unacceptable.
> 
> 2. A non-leaf monitor is being entered while a leaf monitor has been entered: This is also a `LEAF RULE` violation. This violation is at the same time always a "RANK ORDER VIOLATION" for the non-leaf monitor. My view is there is no need to report this "RANK ORDER VIOLATION" as it always coexists with the `LEAF RULE` violation for non-leaf monitors. But if you insist on reporting it additionally then it is not a problem to check and report it in the `assertOrderFailure()` function. It has all needed info available for it.
> 
> 3. A non-leaf monitor is being entered while a non-leaf monitor has been entered: It is a case+report for "RANK ORDER VIOLATION".
> 
> There is one more variant:
> 4. A leaf monitor is being entered while a non-leaf monitor has been entered: It is never a violation, so this variant is excluded from the list above.

But 2 and 1 are very different. You can call them both leaf violations, but they are leaf violations for very different reasons, and 2 is more akin to a rank violation than a leaf violation.

I'm reversing the ranks and reworking the loop a bit (both the comments and how the errors are reported). I'll try to post later tonight after testing is done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1594847727

From syan at openjdk.org  Thu May  9 02:05:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 May 2024 02:05:53 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <ibh25Y2w6yBZQM3Y41pJK-hZsj5pfl_SDzaErloYKlg=.bbc66d78-bf5e-4a95-9002-50bb4fd35ed9@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
 <ibh25Y2w6yBZQM3Y41pJK-hZsj5pfl_SDzaErloYKlg=.bbc66d78-bf5e-4a95-9002-50bb4fd35ed9@github.com>
Message-ID: <gV1yyZfPk9GmX0_Z4QyCEQqlw7ThJ11vzoEW8tAWm4k=.dfd9643d-97fe-40bd-8c9a-9d31f7e0dc88@github.com>

On Wed, 8 May 2024 16:39:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
>
> Marked as reviewed by cjplummer (Reviewer).

@plummercj Thanks for the approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2101797020

From duke at openjdk.org  Thu May  9 04:02:07 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:02:07 GMT
Subject: Withdrawn: 8311846: Resolve duplicate 'Thread' related symbols with
 JDK static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <IAxHoCv2fl_NmcGCc31T_GmTvXgAbq7q4bsRyH35wFg=.a98d5aee-5522-4326-a364-80e31b454c33@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May  9 04:11:02 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:11:02 GMT
Subject: Withdrawn: 8322476: Remove GrowableArray C-Heap version,
 replace usages with GrowableArrayCHeap
In-Reply-To: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com>
References: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com>
Message-ID: <OzThWR5KEDgnJD8IlxEOOuv7j40Dt618tzlKX0Vh698=.9d58d18a-c740-43b1-a698-e3a3cfec703d@github.com>

On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the `GrowableArrayCHeap`. This duplicates the current C-Heap allocation capability in `GrowableArray`. I now remove that from `GrowableArray` and move all usages to `GrowableArrayCHeap`.
> 
> This has a few advantages:
> - Clear separation between arena (and resource area) allocating array and C-heap allocating array.
> - We can prevent assigning / copying between arrays of different allocation strategies already at compile time, and not only with asserts at runtime.
> - We should not have multiple implementations of the same thing (C-Heap backed array).
> - `GrowableArrayCHeap` is NONCOPYABLE. This is a nice restriction, we now know that C-Heap backed arrays do not get copied unknowingly.
> 
> **Bonus**
> We can now restrict `GrowableArray` element type `E` to be `std::is_trivially_destructible<E>::value == true`. The idea is that arena / resource allocated arrays get abandoned, often without being even cleared. Hence, the elements in the array are never destructed. But if we only use elements that are trivially destructible, then it makes no difference if the destructors are ever called, or the elements simply abandoned.
> 
> For `GrowableArrayCHeap`, we expect that the user eventually calls the destructor for the array, which in turn calls the destructors of the remaining elements. Hence, it is up to the user to ensure the cleanup. And so we can allow non-trivial destructors.
> 
> **Testing**
> Tier1-3 + stress testing: pending

This pull request has been closed without being integrated.

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

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

From cjplummer at openjdk.org  Thu May  9 06:10:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 May 2024 06:10:04 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <iRFbdas1EjvfgmqEqz5WyTGci7VFHdO5vtJWAgQJ9NE=.2beff216-4946-4d9d-a53b-33be79363433@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Flip rank order. Some cleanup and better comments for verifyMonitorRank().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/301da7d5..1c6a2e34

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

  Stats: 98 lines in 2 files changed: 31 ins; 18 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/19044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044

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

From jwaters at openjdk.org  Thu May  9 07:50:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:50:00 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Add check for compiler in configure
 - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

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

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=01
  Stats: 334 lines in 19 files changed: 154 ins; 25 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

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

From jwaters at openjdk.org  Thu May  9 07:50:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:50:01 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <L6Nie71UyBRtKtOJsoSAtXLozRfoOnRb2xzJyG0hd1k=.f095eb19-64c2-49aa-9081-cdc08f4868b3@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Please mark the PR as draft it is not intended for review.

@magicus I think I might need some help here. Currently all the Cygwin stuff is gated behind ifeq ($(TOOLCHAIN_TYPE), microsoft) checks... should they be behind isBuildOsEnv cygwin checks instead? I don't know how to add support for Cygwin gcc for most of hsdis, since it is quite different from the more modern gcc distributions that are found in places like MSYS2 and MINGW64. But most of the existing logic seems to accomodate more for the Microsoft compiler than it is concerned about the OS environment being used, and for this reason I can't tell which of the 2 checks to use for the existing hack that switches from microsoft to gcc. Also, gcc doesn't require FIXPATH, but Microsoft does, but I don't want to check for microsoft inside TOOLCHAIN_FIND_COMPILER, what should I do instead to ensure gcc doesn't get FIXPATH while Microsoft does?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2097196121

From jwaters at openjdk.org  Thu May  9 07:56:51 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:56:51 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <77xRfJh_yNfE406Tl9KCpkdlOvGQGzayTUe3fuej-QQ=.3d33f404-3a20-4836-91aa-00469a46018f@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Please mark the PR as draft it is not intended for review.

Also @magicus, what is the typical path passed to --with-binutils like on Windows? Something like --with-binutils=/c/Users/vertig0/Downloads/binutils-2.42 doesn't work correctly, since the include path to dis-asm.h would then become
`#include "/c/Users/vertig0/Downloads/binutils-2.42/include/dis-asm.h"`
Which causes a configure check to fail on the compile stage since gcc cannot recognise the MINGW-esque /c/ as a drive, and then causes configure to erroneously report binutils as using the Old API when it's in fact using the New API. --with-binutils=C:/Users/vertig0/Downloads/binutils-2.42 on the other hand works as expected. Should there be a fixup for the path there so gcc can recognise it properly?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2102146604

From dholmes at openjdk.org  Thu May  9 08:21:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 May 2024 08:21:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

I think we may have to restore this to a standalone start-of-release change done after the other start-of-release changes. I had forgotten about the need to update the flags sections of java.1

src/java.base/share/man/java.1 line 3856:

> 3854: .SH REMOVED JAVA OPTIONS
> 3855: .PP
> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them

This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2047411800
PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1595128505

From kevinw at openjdk.org  Thu May  9 08:31:00 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 May 2024 08:31:00 GMT
Subject: RFR: 8331950: Remove
 MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists
Message-ID: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>

Remove from zgc problemlists.

This was omitted when https://bugs.openjdk.org/browse/JDK-8303136 was integrated.

I see the tests passing, including with ZGC.  Just ran my own batch of tests in addition, and it includes passes with e.g. -XX:+UseZGC -XX:+ZGenerational

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

Commit messages:
 - Remove MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists

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

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

From sspitsyn at openjdk.org  Thu May  9 12:34:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 12:34:53 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <WNWRHYnzL83pF7CMvnhWd-5IQ-q8HhxuZXtA7tCMq8M=.1ea569af-9e37-4b21-bce3-26d798463d25@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
 <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
 <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>
 <tYmZtUV1qz1lDQLuGYgIKZVaAU9kvioo50_
 WSR9v4rI=.8fa6cb1f-0f17-4abf-b4d8-1ec46323bf32@github.com>
 <WNWRHYnzL83pF7CMvnhWd-5IQ-q8HhxuZXtA7tCMq8M=.1ea569af-9e37-4b21-bce3-26d798463d25@github.com>
Message-ID: <IyXLrjzsUBNtUS73pWWjVBrQtlC1UUL6-2Hv9FLZjcU=.8d9956a6-0643-434c-be5b-928f83491a66@github.com>

On Thu, 9 May 2024 01:00:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Okay, thanks. Please, let me list the variants with some analysis.
>> We have 3 variants:
>> 1.  Both monitors are leaf: Entering any monitor while a leaf monitor has been entered is a violation (`LEAF RULE` violation). The order does not matter. Any order is unacceptable.
>> 
>> 2. A non-leaf monitor is being entered while a leaf monitor has been entered: This is also a `LEAF RULE` violation. This violation is at the same time always a "RANK ORDER VIOLATION" for the non-leaf monitor. My view is there is no need to report this "RANK ORDER VIOLATION" as it always coexists with the `LEAF RULE` violation for non-leaf monitors. But if you insist on reporting it additionally then it is not a problem to check and report it in the `assertOrderFailure()` function. It has all needed info available for it.
>> 
>> 3. A non-leaf monitor is being entered while a non-leaf monitor has been entered: It is a case+report for "RANK ORDER VIOLATION".
>> 
>> There is one more variant:
>> 4. A leaf monitor is being entered while a non-leaf monitor has been entered: It is never a violation, so this variant is excluded from the list above.
>
> But 2 and 1 are very different. You can call them both leaf violations, but they are leaf violations for very different reasons, and 2 is more akin to a rank violation than a leaf violation.
> 
> I'm reversing the ranks and reworking the loop a bit (both the comments and how the errors are reported). I'll try to post later tonight after testing is done.

This is updated function `assertOrderFailure()` to print "RANK ORDER" failure for the case #2 above:

static void
assertOrderFailure(jthread thread,  DebugRawMonitorRank rank, DebugRawMonitor* dbg_monitor, char* msg)
{
    char* threadName = getThreadName(thread);
     tty_message("DebugRawMonitor %s failure: (%s: %d > %d) for thread (%s)",
                 msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);

     if (rank < FIRST_LEAF_DEBUG_RAW_MONITOR &&
         dbg_monitor ->rank >= FIRST_LEAF_DEBUG_RAW_MONITOR) {
         tty_message("DebugRawMonitor RANK ORDER failure: (%s: %d > %d) for thread (%s)",
                     msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);
     }
     jvmtiDeallocate(threadName);
     JDI_ASSERT(JNI_FALSE);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1595383612

From sspitsyn at openjdk.org  Thu May  9 12:48:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 12:48:53 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <IGQyEWt64EzKEhwWG98nVVX8GvuVOSJLEjsvmXAd3H0=.c7d626e3-ea91-4bbe-b560-4b1aeb4b90c6@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

PING! Need one more review, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2102593940

From kevinw at openjdk.org  Thu May  9 13:46:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 May 2024 13:46:54 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <jorQIqPjcAs0rmbdpJALNEsXxHsOoIbqJrjsws3-pt8=.9b2a10db-d0af-41a2-a548-3ccc8a585dc6@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

Looks good to me.

post_class_file_load_hook during VirtualThread$VThreadContinuation.onPinned, and because it's the first onPinned call it causes classloading, so just avoid that circular problem (these may not be the class loading events that most people are looking for most of the time).

I wonder if this change is needed only until "jdk.tracePinnedThreads" is removed?  Maybe this becomes unnecessary if TRACE_PINNING_MODE is gone, as maybe there won't be any possible classloading.  Just a thought, no need for any more in this change.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19054#pullrequestreview-2047999334

From sspitsyn at openjdk.org  Thu May  9 14:32:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 14:32:57 GMT
Subject: RFR: 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <6bT9AIygcEud6XlOjx-uuGdQk2DfcU83UZUqnB_dWpQ=.41cd47df-61d0-4e54-a184-7d08bc13783b@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

Thank you for review, Kevin!
The fix is needed anyway independently of the "jdk.tracePinnedThreads" option.

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

PR Comment: https://git.openjdk.org/jdk/pull/19054#issuecomment-2102778109

From sspitsyn at openjdk.org  Thu May  9 14:32:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 14:32:57 GMT
Subject: Integrated: 8330146: assert(!_thread->is_in_any_VTMS_transition())
 failed
In-Reply-To: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
References: <GllShxOTAddPAoxcdx15hku--VfChSf9Qu2B9ppl_VE=.1c6743b6-1b33-4e33-995e-068a3632695e@github.com>
Message-ID: <tzCpiIBAX5cJ39lWmCoWzg5UIMj7Tp3lsFk0qSP9zGQ=.e4d25903-6321-4963-acb6-896370e6ceff@github.com>

On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Any event posting code except CFLH, ClassPrepare and ClassLoad  events has a conditional return in case if the event is posted during a VTMS transition. The CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead. The ClassPrepare and ClassLoad events also have a conditional return in a case of temporary VTMS transition.
> This update is to align the CFLH, ClassPrepare and ClassLoad events with all other events in this area.
> 
> Testing:
>  - TBD: submit mach5 tiers 1-6

This pull request has now been integrated.

Changeset: c4ff58b9
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4ff58b9bcfd08eae0623a648a837e08f25b3f9b
Stats:     9 lines in 1 file changed: 2 ins; 2 del; 5 mod

8330146: assert(!_thread->is_in_any_VTMS_transition()) failed

Reviewed-by: cjplummer, kevinw

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

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

From sspitsyn at openjdk.org  Thu May  9 15:23:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 May 2024 15:23:53 GMT
Subject: RFR: 8331950: Remove
 MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists
In-Reply-To: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
References: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
Message-ID: <1r0sJodflVOfjAZUGtDP6d9My-qDOyqaAWf22sH8BNc=.1974d8bb-2c9d-4843-9a3f-86d0e083c1e4@github.com>

On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove from zgc problemlists.
> Trivial fix.
> 
> This was omitted when https://bugs.openjdk.org/browse/JDK-8303136 was integrated.
> 
> I see the tests passing, including with ZGC.  Just ran my own batch of tests in addition, and it includes passes with e.g. -XX:+UseZGC -XX:+ZGenerational

Looks good and trivial.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19143#pullrequestreview-2048206935

From kevinw at openjdk.org  Thu May  9 15:44:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 May 2024 15:44:56 GMT
Subject: RFR: 8331950: Remove
 MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists
In-Reply-To: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
References: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
Message-ID: <5oaRaNCDV8gAdhI9q-UD8vbmxMygkANgOJTylyZIP1Q=.0a4d793b-1dcf-41b9-abdc-81b838be078d@github.com>

On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove from zgc problemlists.
> Trivial fix.
> 
> This was omitted when https://bugs.openjdk.org/browse/JDK-8303136 was integrated.
> 
> I see the tests passing, including with ZGC.  Just ran my own batch of tests in addition, and it includes passes with e.g. -XX:+UseZGC -XX:+ZGenerational

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/19143#issuecomment-2102918974

From kevinw at openjdk.org  Thu May  9 15:44:57 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 May 2024 15:44:57 GMT
Subject: Integrated: 8331950: Remove
 MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists
In-Reply-To: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
References: <ublsiliIYv0Esn7JhicxRM42pE67FBkpBO550loA2yA=.d62db3ca-f16b-46b6-b8bc-5cad63f921cb@github.com>
Message-ID: <zu7YqB-VaS0zscQ3K5cDHCnwGH_80rO-apLOdZFp8Ik=.d09e3e39-fab6-4744-aa0c-6da4cb2e6df5@github.com>

On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove from zgc problemlists.
> Trivial fix.
> 
> This was omitted when https://bugs.openjdk.org/browse/JDK-8303136 was integrated.
> 
> I see the tests passing, including with ZGC.  Just ran my own batch of tests in addition, and it includes passes with e.g. -XX:+UseZGC -XX:+ZGenerational

This pull request has now been integrated.

Changeset: aa4cddd4
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa4cddd4b8a6a12ba5d0360a721aebaabf362fff
Stats:     2 lines in 2 files changed: 0 ins; 2 del; 0 mod

8331950: Remove MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists

Reviewed-by: sspitsyn

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

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

From matsaave at openjdk.org  Thu May  9 18:31:24 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 May 2024 18:31:24 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v3]
In-Reply-To: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
Message-ID: <jJl0SMBZ8YlmX-uA7C1fab4kcCUopeLdVikd23EgE9o=.61a29914-9a1d-4922-b365-52c788b584e0@github.com>

> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
> 
> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

Matias Saavedra Silva 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 12 additional commits since the last revision:

 - Merge branch 'master' into pointer_to_offset_8329418
 - Ioi comments
 - Chris comments and cleanup
 - Merge branch 'master' into pointer_to_offset_8329418
 - Cleanup
 - Corrected SA
 - Editing SA
 - Fixed dynamic dumping
 - Now works with -Xshare:on
 - Adjusted serialization
 - ... and 2 more: https://git.openjdk.org/jdk/compare/aaa2e59e...11f39483

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19107/files
  - new: https://git.openjdk.org/jdk/pull/19107/files/d40afef9..11f39483

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

  Stats: 17065 lines in 289 files changed: 8650 ins; 5891 del; 2524 mod
  Patch: https://git.openjdk.org/jdk/pull/19107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19107/head:pull/19107

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

From iklam at openjdk.org  Thu May  9 19:59:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 9 May 2024 19:59:54 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v3]
In-Reply-To: <jJl0SMBZ8YlmX-uA7C1fab4kcCUopeLdVikd23EgE9o=.61a29914-9a1d-4922-b365-52c788b584e0@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
 <jJl0SMBZ8YlmX-uA7C1fab4kcCUopeLdVikd23EgE9o=.61a29914-9a1d-4922-b365-52c788b584e0@github.com>
Message-ID: <xfUg9vJLaDmOWWYZHQ2DUo2sBdapqzd5NPs1uKVqbME=.34daf313-86c2-4e3e-9d62-eb787710875d@github.com>

On Thu, 9 May 2024 18:31:24 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
>> 
>> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into pointer_to_offset_8329418
>  - Ioi comments
>  - Chris comments and cleanup
>  - Merge branch 'master' into pointer_to_offset_8329418
>  - Cleanup
>  - Corrected SA
>  - Editing SA
>  - Fixed dynamic dumping
>  - Now works with -Xshare:on
>  - Adjusted serialization
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c6bab5bc...11f39483

LGTM. Just one small nit.

src/hotspot/share/cds/serializeClosure.hpp line 52:

> 50: 
> 51:   // Iterate on the pointers from p[0] through p[num_pointers-1]
> 52:   void do_ptrs(u_char* start, size_t size) {

I think it will be more consistent if we use the same `void** p` parameter as in `do_ptr()`. The `u_char*` here is a historical oddity and should be fixed.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19107#pullrequestreview-2048708441
PR Review Comment: https://git.openjdk.org/jdk/pull/19107#discussion_r1595908706

From matsaave at openjdk.org  Thu May  9 21:08:36 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 May 2024 21:08:36 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v4]
In-Reply-To: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
Message-ID: <2VF1-BhwWyrgDB09gN9mJRsXhptsQQ5n_wZJAaVlWXo=.9c4a5fbc-f815-4452-a514-52eaeea908d2@github.com>

> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
> 
> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  u_char* to void**

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19107/files
  - new: https://git.openjdk.org/jdk/pull/19107/files/11f39483..7fca6588

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

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

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

From dcubed at openjdk.org  Thu May  9 21:29:11 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 May 2024 21:29:11 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on macos-aarch64 [v2]
In-Reply-To: <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
Message-ID: <fjRPqsJpJ6QdAPejl_yWegKDAsahscteN_XrtPKGujg=.5dd2fb43-91cb-4b3d-a09a-8a5d1fc60d11@github.com>

On Wed, 8 May 2024 01:19:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
>> 
>>   Only change the ProblemList, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

I've updated the bug's sysnopsis:

s/macos-aarch64/generic-all/

The fastest way to update the PR's title is with `/issue JDK-8331466`

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2103444424

From dholmes at openjdk.org  Thu May  9 21:44:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 May 2024 21:44:59 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>
Message-ID: <ja6gCoAx-hvhT_33lyZJv2IG2vhix3dE7uKO34jXa8Q=.a8a44872-a07c-4860-b6f4-818a26086458@github.com>

On Mon, 6 May 2024 21:42:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I don't see how that helps. Access to the field is not protected.
>
> I guess there could be a race if one thread is destroying this monitor while another is trying to use it. Thus a thread could be doing something like a RawMonitorEnter in the middle of (or after) the monitor being destroyed. Fixing that would require holding dbgRawMonitor during RawMonitorEnter, and that would cause deadlocks all over the place. Also, this same potential issue exists already, but doesn't seem to ever arise. It seems we only call debugMonitorDestroy for cmdQueueLock. Not sure why that is.

FWIW Deleting monitors is a tricky business and needs to be done with great care. You have to ensure all threads using the monitor are completely done with it. Simply locking it first to check it is "unused" is not sufficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1596015404

From syan at openjdk.org  Fri May 10 01:03:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 May 2024 01:03:05 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on generic-all [v2]
In-Reply-To: <fjRPqsJpJ6QdAPejl_yWegKDAsahscteN_XrtPKGujg=.5dd2fb43-91cb-4b3d-a09a-8a5d1fc60d11@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
 <fjRPqsJpJ6QdAPejl_yWegKDAsahscteN_XrtPKGujg=.5dd2fb43-91cb-4b3d-a09a-8a5d1fc60d11@github.com>
Message-ID: <i03ikUiZ1zULLN9sMpfIvWZg0h0CAo7jUpKm4dzaFyI=.26b6945e-efaa-4710-967f-1adee9b05e82@github.com>

On Thu, 9 May 2024 21:26:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I've updated the bug's sysnopsis:
> 
> s/macos-aarch64/generic-all/
> 
> The fastest way to update the PR's title is with `/issue JDK-8331466`

@dcubed-ojdk  Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2103665202

From jwaters at openjdk.org  Fri May 10 01:04:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 May 2024 01:04:04 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <9cOTNRj5EgyWRkI0hRuNjxym6vY29_GzTJdh4f-JstI=.4c216b65-b596-41f1-9ec1-3720ddca5577@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Please mark the PR as draft it is not intended for review.

@magicus?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2103667760

From matsaave at openjdk.org  Fri May 10 01:37:10 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 10 May 2024 01:37:10 GMT
Subject: RFR: 8329418: Replace pointers to tables with offsets in
 relocation bitmap [v2]
In-Reply-To: <hJqYjPDvnGWdNYTgOe87MmQLoobvTQyYvE7hMzuAk30=.b85d27ca-dc6b-464b-a976-4c1c0b61ba05@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
 <zT6-v1K70YRFz63qN8nzcddIEk-_kHhsPobDYFWxs5E=.1661e58e-cbe3-4dcf-a0e4-dcef69d26e99@github.com>
 <hJqYjPDvnGWdNYTgOe87MmQLoobvTQyYvE7hMzuAk30=.b85d27ca-dc6b-464b-a976-4c1c0b61ba05@github.com>
Message-ID: <CTdPi1WnB4KOYQkoeQQRikdOpyD1WlSAElsRj7GjgPU=.413a7150-4e9a-4bef-89d7-b7220dab951e@github.com>

On Tue, 7 May 2024 21:39:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chris comments and cleanup
>
> SA changes look good. Thanks for taking care of this.

Thanks for the reviews @plummercj and @iklam!

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

PR Comment: https://git.openjdk.org/jdk/pull/19107#issuecomment-2103692236

From matsaave at openjdk.org  Fri May 10 01:37:10 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 10 May 2024 01:37:10 GMT
Subject: Integrated: 8329418: Replace pointers to tables with offsets in
 relocation bitmap
In-Reply-To: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
References: <IHc4ZjLDds0_vn1m_zaAM9rKjk5QpuEgX96HJ1ZZ7M8=.736bfdcd-9cfa-4ec4-b282-073e4fe54070@github.com>
Message-ID: <1BtZbZp_vkiEPIf3xDeZ05CSCh6mnZ2p3qobDuM-aa0=.acaf9e28-1d99-48ee-90fd-0878c99b8ff6@github.com>

On Mon, 6 May 2024 17:05:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The beginning of the RW region contains pointers to c++ vtables which are always located at a fixed offset from the shared base address at runtime. This offset can be calculated at dumptime and stored with the read-only tables at the top of the RO region. As a further improvement, all the pointers to RO tables are replaced with offsets as well.
> 
> These changes will reduce the number of pointers in the RW and RO regions and will allow for the relocation bitmap size optimizations to be more effective. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: a706ca4f
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a706ca4fdb4db4ba36c6ad04a37c37a348f8af0b
Stats:     137 lines in 11 files changed: 64 ins; 24 del; 49 mod

8329418: Replace pointers to tables with offsets in relocation bitmap

Reviewed-by: cjplummer, iklam

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

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

From gli at openjdk.org  Fri May 10 08:44:18 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 May 2024 08:44:18 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v5]
In-Reply-To: <3KivzgORzLhAreonPr-CJki3nXgPznlKMpqI4fQCWuk=.f44a8b19-56e6-4809-ac7b-659d700407af@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <3KivzgORzLhAreonPr-CJki3nXgPznlKMpqI4fQCWuk=.f44a8b19-56e6-4809-ac7b-659d700407af@github.com>
Message-ID: <PP7gy2qzozjqYgt5R5g-bMM11dl0OSJG73ATPQJYlw4=.c1b3e2e9-f681-4f56-b10f-cb468bb4e1f1@github.com>

On Wed, 8 May 2024 10:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
>> 
>> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into s1-do-collect
>  - merge
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - s1-do-collect

Looks good. One suggestion, but not necessary.

src/hotspot/share/gc/serial/serialHeap.cpp line 656:

> 654:   do_full_collection_no_gc_locker(clear_soft_refs);
> 655: }
> 656: 

Maybe the method `do_young_gc` can be renamed to `do_young_collection` or `do_young_collection_no_gc_locker` which is consistent with `do_full_collection` or `do_full_collection_no_gc_locker`.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19056#pullrequestreview-2049609145
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1596463754

From ayang at openjdk.org  Fri May 10 08:55:36 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 May 2024 08:55:36 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into s1-do-collect
 - review
 - Merge branch 'master' into s1-do-collect
 - merge
 - review
 - Merge branch 'master' into s1-do-collect
 - s1-do-collect

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

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=05
  Stats: 566 lines in 15 files changed: 125 ins; 356 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From stuefe at openjdk.org  Fri May 10 10:21:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 May 2024 10:21:49 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file
Message-ID: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>

MEMFLAGS, as well as its enum constants, should live in its own include. 

The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.

The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.

---

This patch moves the enum to its new file.

It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 

For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.

I tested (built) on:
- MacOS aarch64, no precompiled headers, fastdebug
- Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

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

Commit messages:
 - Update g1MonotonicArena.hpp
 - Update g1MonotonicArena.hpp
 - NMT-factor-out-memflags

Changes: https://git.openjdk.org/jdk/pull/19172/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332042
  Stats: 225 lines in 25 files changed: 124 ins; 64 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/19172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19172/head:pull/19172

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

From stuefe at openjdk.org  Fri May 10 10:27:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 May 2024 10:27:10 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file
In-Reply-To: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
Message-ID: <CyeeZHHV6ibQslugZiv2ZlBtMNUemV7GbnUsE1haP2s=.27f30903-50a1-41a3-88bb-0471d69eb848@github.com>

On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

Ping @afshin-zafari @jdksjolen 
@gerard-ziemski

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

PR Comment: https://git.openjdk.org/jdk/pull/19172#issuecomment-2104357678

From dcubed at openjdk.org  Fri May 10 22:12:21 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 10 May 2024 22:12:21 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <OySW23RnwQQOK1Dl721B1uHiculZ6Qx-l0sNm5gRl7E=.7ffd070e-1f0d-4f2a-bbf3-5f7dcbe520b0@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
 <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
 <OySW23RnwQQOK1Dl721B1uHiculZ6Qx-l0sNm5gRl7E=.7ffd070e-1f0d-4f2a-bbf3-5f7dcbe520b0@github.com>
Message-ID: <uW1YBI63VbidNq3eAkOQFUfxOsHFW_ZOTkyWW4IYCrE=.1dda1260-31b0-480a-9d53-cff2b7506ad0@github.com>

On Tue, 30 Apr 2024 01:49:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 366:
>> 
>>> 364:           attempts--;
>>> 365:         }
>>> 366:         DEBUG_ONLY(if (attempts == 0) break;)
>> 
>> Previously `_VTMS_transition_count` considered all threads at the same time. Now you are iterating through the threads and looking at a flag in each one. Is it guaranteed that once the `_VTMS_transition_mark` flag has been verified not to be set in a thread it won't get set while still iterating in the threads loop?
>
> Thank you for the comment. It is thinking in a right direction.
> Each `JavaThread` set the `VTM_transition_mark` only once and then checks for disable counters:
>  - `_VTMS_transition_disable_for_all_count`
>  - `java_lang_Thread::VTMS_transition_disable_count(vth())`
>  
> If any of the disable counters is not zero then each `JavaThread` clears the optimistically set mark and continues under protection of the `JvmtiVTMSTransition_lock`.

I'm not sure this answered Chris' query properly. Or I'm reading Chris' query wrong.

Perhaps this is not what Chris had in mind, but I'm wondering what happens in some
Thread-A when it is checked and passed by but then Thread-A sets the flag in itself
after the for-loop has passed it by. Does that Thread-A flag value get lost?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1597266296

From duke at openjdk.org  Sat May 11 11:15:03 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 11 May 2024 11:15:03 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v9]
In-Reply-To: <3x1oThcCfOj6FR0ZJoH5ipYkrHTFAzrgJXm69Tggb8k=.83dba355-787a-4f05-a721-df5aee8fd810@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <7Aud9EX-Q09Bx3MmZjM182gBp9sDmbvIt7rSmtBa1FM=.cc43a81c-7431-484d-9eae-295da93c9a52@github.com>
 <3x1oThcCfOj6FR0ZJoH5ipYkrHTFAzrgJXm69Tggb8k=.83dba355-787a-4f05-a721-df5aee8fd810@github.com>
Message-ID: <yID3h4oY6lS3Pcl3RJMWDWBXV2cxWMx1bwM_5-nxwuw=.3e5a2b22-6de0-4651-99c1-081c6ed093b3@github.com>

On Mon, 6 May 2024 22:19:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In SA I see references to heapRegionIterate() that possibly should be renamed.
> 
> I noticed that the HeapRegionManager and HeapRegionClosure classes were not renamed (in the hotspot source). Is this intentional or an oversite?

OK, I will do all the SA part here. However, I do think that the other classes named 'HeapRegion*' in the hotspot source should be dealt with in follow-up PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2105680607

From duke at openjdk.org  Sun May 12 02:55:45 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 12 May 2024 02:55:45 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v10]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <Z16kBF-kDCLh-VDVvsDrwJ1-pVLwST74VWne2j-Mp0g=.981deb5e-eff7-4ce8-8bdb-bbbbd4d43b92@github.com>

> follow up 8267941

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

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/b007eb01..65a4bbf9

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

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

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

From duke at openjdk.org  Sun May 12 03:07:15 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 12 May 2024 03:07:15 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v10]
In-Reply-To: <Z16kBF-kDCLh-VDVvsDrwJ1-pVLwST74VWne2j-Mp0g=.981deb5e-eff7-4ce8-8bdb-bbbbd4d43b92@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <Z16kBF-kDCLh-VDVvsDrwJ1-pVLwST74VWne2j-Mp0g=.981deb5e-eff7-4ce8-8bdb-bbbbd4d43b92@github.com>
Message-ID: <Xd_ryNOHz9OptFCJsA5xghtyVGsN3JNHxVKtuPNzEmw=.1a558889-ed1e-4fcf-95c2-761bc98a8ec0@github.com>

On Sun, 12 May 2024 02:55:45 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

Should we also rename 'HeapRegionType' to 'G1HeapRegionType', then rename the current 'G1HeapRegionType' to 'G1 HeapRegionTypeEnum'?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java line 131:

> 129:             if (hr.isInRegion(addr)) {
> 130:                 return hr;
> 131:             }

Since these three methods are G1 specific, I'd prefer not to add the 'g1' prefix.

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

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2051282649
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1597540754

From duke at openjdk.org  Sun May 12 06:01:27 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 12 May 2024 06:01:27 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v11]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <-TstTKGbE-Ewn6GcQHrBqW4XQPpeMmOwxb-TeeXMLdA=.4e38776a-1439-4112-9350-9cec07c0bd83@github.com>

> follow up 8267941

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

  fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/65a4bbf9..dafdc775

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

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

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

From azafari at openjdk.org  Sun May 12 17:54:03 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Sun, 12 May 2024 17:54:03 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file
In-Reply-To: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
Message-ID: <lVp9SLXC_Wad6DqMpMOOHmUzaeMAavs6RmtuNEek3KY=.bfe0d48d-7615-4ece-a15f-f87207e2f2ef@github.com>

On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

src/hotspot/share/services/mallocLimit.hpp line 3:

> 1: /*
> 2:  * Copyright (c) 2023 SAP SE. All rights reserved.
> 3:  * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved.

Maybe 2023, 2024 instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1597683285

From duke at openjdk.org  Sun May 12 18:42:03 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Sun, 12 May 2024 18:42:03 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
 <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>
Message-ID: <5jtxG7mdbPDU7_iroUJP04Kut6e7o1_5XF2Ht_L9ciE=.67b51646-bcab-4fe8-a192-9d8e63a3e31b@github.com>

On Mon, 6 May 2024 18:31:06 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked attach logic
>
> On 5/6/24 10:35 AM, Sebastian L?vdahl wrote:
>>
>> I pushed an updated attempt at this now with d3e26a0 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d3e26a0c444e06ba9757fd528d72d83f56cd098b__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svPHZrq9ZQ$>. 
>> Local testing and |make test 
>> TEST="jtreg:test/hotspot/jtreg/containers"| + |make test 
>> TEST="jtreg:test/hotspot/jtreg/serviceability"| indicate that all the 
>> known use-cases work.
>>
>> Still eager to see what you come up with @larry-cable 
>> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNMPdGFLg$>. 
>> |createAttachFile| could still be improved for example. And I would 
>> also be interested in looking into writing some test for the elevated 
>> privileges case.
>>
>> ?
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2096564990__;Iw!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNUwHWtZA$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGOTAXCKY2TO2OBDDZA65N5AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGU3DIOJZGA__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svO2ymONGw$>.
>> You are receiving this because you were mentioned.Message ID: 
>> ***@***.***>
>>
> 
> 
>  ?/*
> diff --git 
> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> index 81d4fd259ed..c148dbd61b7 100644
> --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> @@ -34,6 +34,7 @@
>  ?import java.nio.file.Path;
>  ?import java.nio.file.Paths;
>  ?import java.nio.file.Files;
> +import java.util.Optional;
> 
>  ?import static java.nio.charset.StandardCharsets.UTF_8;
> 
> @@ -46,8 +47,28 @@ public class VirtualMachineImpl extends 
> HotSpotVirtualMachine {
>  ???? // location is the same for all processes, otherwise the tools
>  ???? // will not be able to find all Hotspot processes.
>  ???? // Any changes to this needs to be synchronized with HotSpot.
> -??? private static final String tmpdir = "/tmp";
> +??? private static final Path TMPD...

Thanks for all the deep thinking you're doing here @larry-cable, appreciated. And sorry for the delay in my response, I'll try to get more time devoted to this during the coming week.

> I did some thinking on this issue over the weekend and came up with an
> idea that *may* improve the probability of an attach succeeding in the
> case that the target has elevated privileges and the jcmd is not in the
> same mnt namespace as the target JVM.

I haven't fully digested the patches you have provided yet, but one question this far. In these cases, is it not a requirement that `jcmd` is run as `root`? So even if the target process is run with elevated privileges, attaching would always work. Or is there some way to attach from host to container with a non-`root` user that I'm missing?

One thing I would like to eventually achieve is to have [JDK-8226919](https://bugs.openjdk.org/browse/JDK-8226919) and this fix backported to the current LTS releases. Would it make more sense to fix [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) with as few changes as possible, and use that for backports, and do more extensive improvements in a separate follow-up that don't need backporting?

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2106339738

From duke at openjdk.org  Sun May 12 19:27:26 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 12 May 2024 19:27:26 GMT
Subject: RFR: 8332098: Add missing `@since` tags to `jdk.jdi`
Message-ID: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>

Please review this simple change where I add `@since` tags to the package-info file of the following packages
```com.sun.jdi
com.sun.jdi.connect
com.sun.jdi.connect.spi
com.sun.jdi.event
com.sun.jdi.request

I used the unix `grep` command to find the oldest `@since` in each package and used that value, as it's hard to get the source code of JDK 1-5
TIA

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

Commit messages:
 - Add `@since` tags to package-info.java

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

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

From lmesnik at openjdk.org  Sun May 12 21:38:32 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 12 May 2024 21:38:32 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't be Finalizable
Message-ID: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>

The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760

The cleanup method flush stream and print summary which should be already printed by complain method.

This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.

Note: The 'verboseOnErrorEnabled' is just not used.

See isVerboseOnErrorEnabled.
    public boolean isVerboseOnErrorEnabled() {
- return errorsSummaryEnabled;
- }

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

Commit messages:
 - revertdc removal
 - 8332112: Update nsk.share.Log to don't be Finalizable

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

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

From dlong at openjdk.org  Sun May 12 22:26:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Sun, 12 May 2024 22:26:04 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <m6bQAl_exnCb2wAGMQ3PkMms2WhbfgVBXLLnhgZloWM=.ea6fa98e-6c6e-430f-996c-98f0d4fe578d@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

I think there is a sweet-spot middle-ground between the two extremes: full-lazy, ideal for performance, and fine-grained execute-by-default, ideal for security.  I don't think we should change to full-lazy and remove all the guard rails at this time.  I am investigating execute-by-default, and it looks promising.

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

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18762#pullrequestreview-2051465621

From dholmes at openjdk.org  Mon May 13 01:47:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 May 2024 01:47:05 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't be Finalizable
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <RjyBkHc1TMY2UPbM0r6Wk_uLyMNRIVUU9D6YQOT6a6c=.787a6db4-d5e2-49a6-85c7-a4a808b8dfa3@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

There seems to be very little in this PR that pertains to "finalize" so perhaps the JBS title etc could be updated to reflect what most of this PR is actually about.

> However, now it is called only during shutdown hook. 

Where does this get set up?

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

PR Review: https://git.openjdk.org/jdk/pull/19209#pullrequestreview-2051556955

From jwaters at openjdk.org  Mon May 13 04:26:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 13 May 2024 04:26:02 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <0TRavDTT-tP_CWDMxGtcwZawPjWA_Ee5Uxcay8NXbao=.99b25023-3008-4172-b537-d8a78ccbe71b@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Please mark the PR as draft it is not intended for review.

@magicus?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2106619396

From stuefe at openjdk.org  Mon May 13 04:55:24 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 May 2024 04:55:24 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
Message-ID: <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update mallocLimit.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19172/files
  - new: https://git.openjdk.org/jdk/pull/19172/files/9a27048a..42361558

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

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

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

From jsjolen at openjdk.org  Mon May 13 06:26:04 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 13 May 2024 06:26:04 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
Message-ID: <H0hlhOpsDuevZELprEcqLv6Lo0Eo9AT4mzj9kY5K8eg=.2a71b85e-7512-4128-a381-a1e24b47ee1c@github.com>

On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> MEMFLAGS, as well as its enum constants, should live in its own include. 
>> 
>> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
>> 
>> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
>> 
>> ---
>> 
>> This patch moves the enum to its new file.
>> 
>> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
>> 
>> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
>> 
>> I tested (built) on:
>> - MacOS aarch64, no precompiled headers, fastdebug
>> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update mallocLimit.hpp

Seems reasonable and LGTM, thanks.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19172#pullrequestreview-2051788348

From alanb at openjdk.org  Mon May 13 06:52:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 06:52:16 GMT
Subject: RFR: 8332098: Add missing `@since` tags to `jdk.jdi`
In-Reply-To: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
Message-ID: <P3EV9bkgCqR86fWKi0MJ712FPYckCJzPqWz9vO3ZZp8=.d73b32de-7352-4501-a8f6-2d455ca57db0@github.com>

On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple change where I add `@since` tags to the package-info file of the following packages
> ```com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
> 
> I used the unix `grep` command to find the oldest `@since` in each package and used that value, as it's hard to get the source code of JDK 1-5
> TIA

Marked as reviewed by alanb (Reviewer).

JPDA was added to the JDK in JDK 1.3. The support for pluggable connectors (added com.sun.jdi.connect.spi package) was JDK 5. So I think this looks okay.

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

PR Review: https://git.openjdk.org/jdk/pull/19200#pullrequestreview-2051829289
PR Comment: https://git.openjdk.org/jdk/pull/19200#issuecomment-2106779971

From tschatzl at openjdk.org  Mon May 13 08:59:11 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 May 2024 08:59:11 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v11]
In-Reply-To: <-TstTKGbE-Ewn6GcQHrBqW4XQPpeMmOwxb-TeeXMLdA=.4e38776a-1439-4112-9350-9cec07c0bd83@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <-TstTKGbE-Ewn6GcQHrBqW4XQPpeMmOwxb-TeeXMLdA=.4e38776a-1439-4112-9350-9cec07c0bd83@github.com>
Message-ID: <oOoAjh2ZbU7I3JQa27WwOUV41FO9ua0R9A6IXET_AH0=.7b013d7a-0e93-4690-b34c-95c50a4daf52@github.com>

On Sun, 12 May 2024 06:01:27 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

I'm good with leaving the `heapRegionIterator()` method name as is, but please make sure that @plummercj is good with this too.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2052094846

From stefank at openjdk.org  Mon May 13 10:22:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 May 2024 10:22:09 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
Message-ID: <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>

On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> MEMFLAGS, as well as its enum constants, should live in its own include. 
>> 
>> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
>> 
>> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
>> 
>> ---
>> 
>> This patch moves the enum to its new file.
>> 
>> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
>> 
>> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
>> 
>> I tested (built) on:
>> - MacOS aarch64, no precompiled headers, fastdebug
>> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update mallocLimit.hpp

Changes requested by stefank (Reviewer).

src/hotspot/share/nmt/mallocTracker.hpp line 29:

> 27: #define SHARE_NMT_MALLOCTRACKER_HPP
> 28: 
> 29: #include "nmt/memflags.hpp"

Should go after mallocHeader.hpp

src/hotspot/share/nmt/memflags.cpp line 27:

> 25: #include "precompiled.hpp"
> 26: 
> 27: #include "nmt/memflags.hpp"

There should be no blankline between precompiled.hpp and the rest of the includes.

src/hotspot/share/nmt/memflags.cpp line 31:

> 29: 
> 30: // Extra insurance that MEMFLAGS truly has the same size as uint8_t.
> 31: STATIC_ASSERT(sizeof(MEMFLAGS) == sizeof(uint8_t));

I think you can remove this entire .cpp file. There's no need to check the size of an enum with a specified base type.

src/hotspot/share/nmt/memflags.hpp line 30:

> 28: #include "utilities/globalDefinitions.hpp"
> 29: 
> 30: #define MEMORY_TYPES_DO(f)                                                           \

Open-ended comment/question: We call it MEMORY_TYPE and mt, but then we call the type MEMFLAGS (with a completely non-standard UPPERCASE style). Maybe it is time to rename MEMFLAGS?

src/hotspot/share/services/mallocLimit.cpp line 28:

> 26: #include "precompiled.hpp"
> 27: 
> 28: #include "nmt/memflags.hpp"

While poking around in the includes, could you remove the blankline on 27. This style inconsistency has slowly crept into the code base.

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

PR Review: https://git.openjdk.org/jdk/pull/19172#pullrequestreview-2052269037
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598224275
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598225428
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598226640
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598229830
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598231329

From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI
Message-ID: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>

This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:

* `System::load` and `System::loadLibrary` are now restricted methods
* `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
* binding a JNI `native` method declaration to a native implementation is now considered a restricted operation

This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.

Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.

Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/19213/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331671
  Stats: 466 lines in 99 files changed: 301 ins; 53 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

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

From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/javadoc/api/index.html
Specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/specdiff_out/overview-summary.html

make/conf/module-loader-map.conf line 105:

> 103:     java.smartcardio \
> 104:     jdk.accessibility \
> 105:     jdk.attach \

The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

src/hotspot/share/prims/nativeLookup.cpp line 277:

> 275: 
> 276:   Klass*   klass = vmClasses::ClassLoader_klass();
> 277:   Handle jni_class(THREAD, method->method_holder()->java_mirror());

This is the biggest change in this PR. That is, we need to pass enough arguments to `ClassLoader::findNative` so that the method can start a restricted check accordingly.

src/java.base/share/classes/java/lang/Module.java line 311:

> 309:         Module target = moduleForNativeAccess();
> 310:         ModuleBootstrap.IllegalNativeAccess illegalNativeAccess = ModuleBootstrap.illegalNativeAccess();
> 311:         if (illegalNativeAccess != ModuleBootstrap.IllegalNativeAccess.ALLOW &&

There are some changes in this code:
* this code is no-op if `--illegal-native-access` is set to `allow`
* we also attach the location of the problematic class to the warning message, using `CodeSource`
* we use the "initial error stream" to emit the warning, similarly to what is done for other runtime warnings

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 115:

> 113:     @ForceInline
> 114:     public static void ensureNativeAccess(Class<?> currentClass, Class<?> owner, String methodName) {
> 115:         if (VM.isModuleSystemInited()) {

If we call this code too early, we can see cases where `module` is `null`.

src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:

> 59:     }
> 60: 
> 61:     @SuppressWarnings({"removal", "restricted"})

There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/module-info.java line 24:

> 22:  */
> 23: 
> 24: module panama_jni_load_module {

This module setup is a bit convoluted, but I wanted to make sure that we got separate warnings for `System.loadLibrary` and binding of the `native` method, and that warning on the _use_ of the native method was not generated (typically, all three operations occur in the same module).

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107272261
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598269825
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598271285
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598274987
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598276455
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598277853
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598279827

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v2]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Avoid call to VM::isModuleSystemInited
  Use initial error stream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/d9fe9a71..c4938dc7

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

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

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

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v2]
In-Reply-To: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
Message-ID: <I64gRu7YBocAbIcJtlBlzXf9kdrDhS8Qu93w-dKXlOY=.ce21de82-c7e0-4a51-b36a-ae8fc88a8ec1@github.com>

On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid call to VM::isModuleSystemInited
>   Use initial error stream

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 124:

> 122:         if (module != null) {
> 123:             // not in init phase
> 124:             Holder.JLA.ensureNativeAccess(module, owner, methodName, currentClass);

In an earlier iteration I had a call to `VM::isModuleSystemInited`, but I discovered that caused a performance regression, since that method involves a volatile access. Perhaps we should rethink that part of the init code to use stable fields, but it's probably better done separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598328283

From mcimadamore at openjdk.org  Mon May 13 11:47:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:47:38 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Fix another typo
 - Fix typo
 - Add more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/c4938dc7..bad10942

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

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

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

From prappo at openjdk.org  Mon May 13 12:59:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 12:59:08 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
 <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
Message-ID: <Bs24lao4Q9KgrEy0OT7WG_Y_79LTVcLSXYZ7Xz27xi8=.6c24caf8-9ff3-43ab-ad9c-1694dd624caf@github.com>

On Thu, 9 May 2024 08:18:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
> 
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them
> 
> This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

David, my understanding is that you agree that this is okay (per our out-of-band, follow-up discussion).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1598432769

From eastigeevich at openjdk.org  Mon May 13 13:11:15 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 13:11:15 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods with
 compiler directives
Message-ID: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>

Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues.

Found bugs:
- When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
- A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.

There are other concerns: bugs and performance issues.

Possible bugs:
- `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
- A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
- JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.

Performance issues:
- Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.

The backout is not clean because of removal of `CompiledMethod`.

Tested with release and fastdebug builds: tier1  and tier2 passed.

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

Commit messages:
 - 8332111: [BACKOUT] A way to align already compiled methods with compiler directives

Changes: https://git.openjdk.org/jdk/pull/19215/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332111
  Stats: 380 lines in 15 files changed: 3 ins; 347 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/19215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19215/head:pull/19215

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

From shade at openjdk.org  Mon May 13 13:21:05 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 13 May 2024 13:21:05 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <_Hf9ur_fzBA6MysoCZHn7KAjJwC0ubP8v4SKBvethOw=.63d58c21-c8ef-4b5a-b878-7fd330e0d654@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues.
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

The reversal looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19215#pullrequestreview-2052683089

From erikj at openjdk.org  Mon May 13 13:23:11 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 May 2024 13:23:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <SWx03p48zvHP1Ij-QdX_jp8Asy7CJKXNeN22LE20H9Q=.f966cc14-6d7d-48b0-96f9-6f04efa105b2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Build changes look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107563120

From weijun at openjdk.org  Mon May 13 13:48:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 13 May 2024 13:48:23 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <aWi7nGuAWfgfr8Zav9c827Na7XNHhgqJyW30njaf3IU=.435796f8-6007-4d00-ac3e-afc3a07e1d3c@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

security changes (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`, and `jdk.security.auth`) look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107621474

From dchuyko at openjdk.org  Mon May 13 13:55:10 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 13 May 2024 13:55:10 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <qYxDd-DTJVQXhUCOYQ8Ogzni0_OrUvrkTOZNLJqPb4s=.17bb1ceb-35f6-4521-8614-3d09ec9c6f97@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

Are there any high severity problems caused by the original PR? Especially not in the new functionality. Minor issues could be probably addressed without backing out the entire functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2107638223

From dfuchs at openjdk.org  Mon May 13 14:18:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 May 2024 14:18:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <YAZUq9RulpAueG36Dq_BhXOH2xeUZVgZCK59PdoR4fQ=.b40434ab-ee39-4e7c-90ec-49655dfa54a2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Changes to jdk.net and jdk.sctp look ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107695217

From eastigeevich at openjdk.org  Mon May 13 14:24:18 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 14:24:18 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <qYxDd-DTJVQXhUCOYQ8Ogzni0_OrUvrkTOZNLJqPb4s=.17bb1ceb-35f6-4521-8614-3d09ec9c6f97@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <qYxDd-DTJVQXhUCOYQ8Ogzni0_OrUvrkTOZNLJqPb4s=.17bb1ceb-35f6-4521-8614-3d09ec9c6f97@github.com>
Message-ID: <m7t5r2Q2jjPBc83LHdLobx3ymA7fcaHNO4XMG96YXjY=.11a3e4c7-4113-45a1-9490-07e6bbf3f564@github.com>

On Mon, 13 May 2024 13:52:17 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> Are there any high severity problems caused by the original PR? Especially not in the new functionality. Minor issues could be probably addressed without backing out the entire functionality.

Yes, there are:

> 1. Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, CodeCache::recompile_marked_directives_matches will be traversing nmethods most of which don't need recompilation.
> 2. has_matching_directives might not be cleared. 
> 3. A Java method is not recompiled as requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2107720199

From stuefe at openjdk.org  Mon May 13 14:31:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 May 2024 14:31:10 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
Message-ID: <dsHXwakOEbgffTVz2yyJ8aW_K78MijAC1MoLlHA0uDE=.afaef773-a738-4e65-9151-7a25576faadd@github.com>

On Mon, 13 May 2024 10:16:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.hpp line 30:
> 
>> 28: #include "utilities/globalDefinitions.hpp"
>> 29: 
>> 30: #define MEMORY_TYPES_DO(f)                                                           \
> 
> Open-ended comment/question: We call it MEMORY_TYPE and mt, but then we call the type MEMFLAGS (with a completely non-standard UPPERCASE style). Maybe it is time to rename MEMFLAGS?

I don't feel like starting that particular bike shedding discussion :) But sure, sometime in the future we should do this. Here, I want it to be a simple renaming change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598580049

From stuefe at openjdk.org  Mon May 13 14:34:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 May 2024 14:34:04 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
Message-ID: <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>

On Mon, 13 May 2024 10:13:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.cpp line 31:
> 
>> 29: 
>> 30: // Extra insurance that MEMFLAGS truly has the same size as uint8_t.
>> 31: STATIC_ASSERT(sizeof(MEMFLAGS) == sizeof(uint8_t));
> 
> I think you can remove this entire .cpp file. There's no need to check the size of an enum with a specified base type.

I rather have this explicit check. If MEMFLAGS>1byte, things break, and I would like to make that explicit.

That said, I can move this static assert to the header. I just wanted to avoid including debug.hpp. My original intent was for this cpp file to be the place in the future for any MEMFLAGS related utility functions, e.g. to-and-from-string conversations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598583814

From dchuyko at openjdk.org  Mon May 13 14:37:03 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 13 May 2024 14:37:03 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <m7t5r2Q2jjPBc83LHdLobx3ymA7fcaHNO4XMG96YXjY=.11a3e4c7-4113-45a1-9490-07e6bbf3f564@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <qYxDd-DTJVQXhUCOYQ8Ogzni0_OrUvrkTOZNLJqPb4s=.17bb1ceb-35f6-4521-8614-3d09ec9c6f97@github.com>
 <m7t5r2Q2jjPBc83LHdLobx3ymA7fcaHNO4XMG96YXjY=.11a3e4c7-4113-45a1-9490-07e6bbf3f564@github.com>
Message-ID: <7kfgb5FXqda4SzqPO2XUXdx6CM_Z-G970nSpqvJVSYw=.b6b01073-66af-4c7d-8d7c-528a4f87707d@github.com>

On Mon, 13 May 2024 14:21:35 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Are there any high severity problems caused by the original PR? Especially not in the new functionality. Minor issues could be probably addressed without backing out the entire functionality.
> 
> 
> 
> Yes, there are:
> 
> 
> 
> > 1. Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, CodeCache::recompile_marked_directives_matches will be traversing nmethods most of which don't need recompilation.
> 
> > 2. has_matching_directives might not be cleared. 
> 
> > 3. A Java method is not recompiled as requested.
> 
> 

So there are cases when new functionality doesn't work as expected (I don't see any other users impacted). Why not file bugs for those cases and estimate their impact?

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2107777980

From eastigeevich at openjdk.org  Mon May 13 14:45:02 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 14:45:02 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <7kfgb5FXqda4SzqPO2XUXdx6CM_Z-G970nSpqvJVSYw=.b6b01073-66af-4c7d-8d7c-528a4f87707d@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <qYxDd-DTJVQXhUCOYQ8Ogzni0_OrUvrkTOZNLJqPb4s=.17bb1ceb-35f6-4521-8614-3d09ec9c6f97@github.com>
 <m7t5r2Q2jjPBc83LHdLobx3ymA7fcaHNO4XMG96YXjY=.11a3e4c7-4113-45a1-9490-07e6bbf3f564@github.com>
 <7kfgb5FXqda4SzqPO2XUXdx6CM_Z-G970nSpqvJVSYw=.b6b01073-66af-4c7d-8d7c-528a4f87707d@github.com>
Message-ID: <ERlfNEB1LiYSOwn_wQD7-HjCnGrf0tSWbi1zMpXW2KY=.33f38652-13e9-4080-a73b-2c742830e567@github.com>

On Mon, 13 May 2024 14:34:50 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> So there are cases when new functionality doesn't work as expected (I don't see any other users impacted). Why not file bugs for those cases and estimate their impact?

Do you know any users using the new functionality?

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2107799744

From eastigeevich at openjdk.org  Mon May 13 14:45:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 14:45:03 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

IMO if nobody uses it and the amount of code is small, it is better to back out it and to reimplement it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2107809381

From stefank at openjdk.org  Mon May 13 14:54:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 May 2024 14:54:05 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
Message-ID: <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>

On Mon, 13 May 2024 14:31:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/nmt/memflags.cpp line 31:
>> 
>>> 29: 
>>> 30: // Extra insurance that MEMFLAGS truly has the same size as uint8_t.
>>> 31: STATIC_ASSERT(sizeof(MEMFLAGS) == sizeof(uint8_t));
>> 
>> I think you can remove this entire .cpp file. There's no need to check the size of an enum with a specified base type.
>
> I rather have this explicit check. If MEMFLAGS>1byte, things break, and I would like to make that explicit.
> 
> That said, I can move this static assert to the header. I just wanted to avoid including debug.hpp. My original intent was for this cpp file to be the place in the future for any MEMFLAGS related utility functions, e.g. to-and-from-string conversations.

Could you instead put the static_assert near the code that will break? Right now it looks obscure and weird to have this check when it is obviously correct as long as no one changes the definition. Would it be enough to write a comment in the header that this needs to be 1 byte?

>> src/hotspot/share/nmt/memflags.hpp line 30:
>> 
>>> 28: #include "utilities/globalDefinitions.hpp"
>>> 29: 
>>> 30: #define MEMORY_TYPES_DO(f)                                                           \
>> 
>> Open-ended comment/question: We call it MEMORY_TYPE and mt, but then we call the type MEMFLAGS (with a completely non-standard UPPERCASE style). Maybe it is time to rename MEMFLAGS?
>
> I don't feel like starting that particular bike shedding discussion :) But sure, sometime in the future we should do this. Here, I want it to be a simple renaming change.

Right. That's why I prefixed this with "Open-ended comment/question", trying to make it super clear that it wasn't intended as a request for this PR, but rather a way to at least plant the seed of an idea that we might want to fix this eyesore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598603277
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598608110

From dcubed at openjdk.org  Mon May 13 15:30:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 13 May 2024 15:30:07 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
 <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
Message-ID: <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com>

On Mon, 13 May 2024 14:44:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I rather have this explicit check. If MEMFLAGS>1byte, things break, and I would like to make that explicit.
>> 
>> That said, I can move this static assert to the header. I just wanted to avoid including debug.hpp. My original intent was for this cpp file to be the place in the future for any MEMFLAGS related utility functions, e.g. to-and-from-string conversations.
>
> Could you instead put the static_assert near the code that will break? Right now it looks obscure and weird to have this check when it is obviously correct as long as no one changes the definition. Would it be enough to write a comment in the header that this needs to be 1 byte?

To quote @robehn - Why write a comment for a rule if you can enforce it with code instead...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598665179

From alanb at openjdk.org  Mon May 13 15:35:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 15:35:08 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/runtime/arguments.cpp line 2271:

> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
> 2271:         return JNI_ENOMEM;

I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598673962

From stefank at openjdk.org  Mon May 13 15:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 May 2024 15:39:17 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
 <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
 <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com>
Message-ID: <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com>

On Mon, 13 May 2024 15:26:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Could you instead put the static_assert near the code that will break? Right now it looks obscure and weird to have this check when it is obviously correct as long as no one changes the definition. Would it be enough to write a comment in the header that this needs to be 1 byte?
>
> To quote @robehn - Why write a comment for a rule if you can enforce it with code instead...

I tend to agree with that. My earlier question still stands is there a better place to put it? Right now the "enforced" code in a stand-alone file doesn't tell me "why" this is important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598679057

From stefank at openjdk.org  Mon May 13 15:51:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 May 2024 15:51:11 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
 <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
 <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com>
 <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com>
Message-ID: <jD8jfJeM_GyOvpD4K1VUuVCbaVdcbIZDrINJNoBA_Zw=.2d745cc5-3057-490d-9c03-05cb6c7ee778@github.com>

On Mon, 13 May 2024 15:36:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> To quote @robehn - Why write a comment for a rule if you can enforce it with code instead...
>
> I tend to agree with that. My earlier question still stands: is there a better place to put it? Right now the "enforced with code" in a stand-alone file doesn't tell me "why" this rule is important.

If you want to keep the static_assert it in the .cpp file, then I won't block that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1598695748

From lmesnik at openjdk.org  Mon May 13 15:56:17 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 13 May 2024 15:56:17 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't be Finalizable
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <eHWcowHHgIRpeLhOYTx-Kbqi8uBiSMHXg2yO4OKKHqM=.3882612f-929e-4a99-8874-2d0ff2e19cb3@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

Every log (as any Finalazible object) is registered using
registerCleanup()
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/Finalizable.java#L59
This function add object to FinalizerThread stack . This stack is processed  and method cleanup is called for each object during shutdown.
See 
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/Finalizer.java#L105
for adding hook
and
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/Finalizer.java#L118
for processing methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/19209#issuecomment-2108082162

From lmesnik at openjdk.org  Mon May 13 16:00:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 13 May 2024 16:00:14 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't be Finalizable
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <oX4cjSYzWD551Vtht8d6o3sNOYGNutzrRr95jg34BWI=.1ee14d47-7cca-49ce-8b80-c9ce303feb08@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

Please, not that shutdown hook is not compatible with jtreg agentvm execution. Really, it is not the recommended to use System.exit() and do something after main() in jtreg. Even in main/othervm mode jtreg call class using some wrapper.
This worked differently in previous in tonga and need to be adopted.

So the plan is to remove such cleanup as much as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/19209#issuecomment-2108091553

From kvn at openjdk.org  Mon May 13 16:32:15 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 May 2024 16:32:15 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>
Message-ID: <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>

On Mon, 13 May 2024 14:42:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
>> 
>> Found bugs:
>> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
>> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
>> 
>> There are other concerns: bugs and performance issues.
>> 
>> Possible bugs:
>> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
>> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
>> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
>> 
>> Performance issues:
>> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
>> 
>> The backout is not clean because of removal of `CompiledMethod`.
>> 
>> Tested with release and fastdebug builds: tier1  and tier2 passed.
>
> IMO if nobody uses it and the amount of code is small, it is better to back out it and to reimplement it.

@eastig do you have tests which shows issues you listed in description? I don't see any reference to them in this sub-task and in [REDO] bug [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
How you found these issues?

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108154151

From cjplummer at openjdk.org  Mon May 13 17:30:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 17:30:05 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v9]
In-Reply-To: <yID3h4oY6lS3Pcl3RJMWDWBXV2cxWMx1bwM_5-nxwuw=.3e5a2b22-6de0-4651-99c1-081c6ed093b3@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <7Aud9EX-Q09Bx3MmZjM182gBp9sDmbvIt7rSmtBa1FM=.cc43a81c-7431-484d-9eae-295da93c9a52@github.com>
 <3x1oThcCfOj6FR0ZJoH5ipYkrHTFAzrgJXm69Tggb8k=.83dba355-787a-4f05-a721-df5aee8fd810@github.com>
 <yID3h4oY6lS3Pcl3RJMWDWBXV2cxWMx1bwM_5-nxwuw=.3e5a2b22-6de0-4651-99c1-081c6ed093b3@github.com>
Message-ID: <X2VPmoaKh4MGF-WbwQUhGuzliclYSvvfYumLURrncgs=.4615af0c-d2b8-4c5e-b1fc-9698347f0136@github.com>

On Sat, 11 May 2024 11:12:44 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> > I noticed that the HeapRegionManager and HeapRegionClosure classes were not renamed (in the hotspot source). Is this intentional or an oversite?
> 
> OK, I will do all the SA part here. However, I do think that the other classes named 'HeapRegion*' in the hotspot source should be dealt with in follow-up PRs.

I think there was a misunderstanding here. I was not asking you to rename these in SA. I was asking why they were not renamed in hotspot. If you want to do them in a follow-up then that is ok, but both hotspot and SA should be done together. So that means either undoing the most recent SA change or applying the same rename change to hotspot.

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2108342113

From cjplummer at openjdk.org  Mon May 13 17:35:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 17:35:08 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v10]
In-Reply-To: <Xd_ryNOHz9OptFCJsA5xghtyVGsN3JNHxVKtuPNzEmw=.1a558889-ed1e-4fcf-95c2-761bc98a8ec0@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <Z16kBF-kDCLh-VDVvsDrwJ1-pVLwST74VWne2j-Mp0g=.981deb5e-eff7-4ce8-8bdb-bbbbd4d43b92@github.com>
 <Xd_ryNOHz9OptFCJsA5xghtyVGsN3JNHxVKtuPNzEmw=.1a558889-ed1e-4fcf-95c2-761bc98a8ec0@github.com>
Message-ID: <BAo_ZIPr9E2E_1CGKK5COdjVtr0sIKh7kHJwyTaTNKQ=.95ae597b-56a9-498c-aa8b-4bab6a8504ac@github.com>

On Sun, 12 May 2024 03:04:45 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> Should we also rename 'HeapRegionType' to 'G1HeapRegionType', then rename the current 'G1HeapRegionType' to 'G1 HeapRegionTypeEnum'?

For this PR the SA renames should match the hotspot renames. It looks like you have not renamed this in hotspot yet so it should not be renamed in SA either.

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2108362277

From kbarrett at openjdk.org  Mon May 13 18:30:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 May 2024 18:30:04 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
Message-ID: <4m9MF6p8mpiKijVsc-mg0IDBQE9lLvPZQjqzZeV1kQo=.97de93cf-8f20-406a-886b-a7c98bd3ccb1@github.com>

On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> MEMFLAGS, as well as its enum constants, should live in its own include. 
>> 
>> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
>> 
>> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
>> 
>> ---
>> 
>> This patch moves the enum to its new file.
>> 
>> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
>> 
>> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
>> 
>> I tested (built) on:
>> - MacOS aarch64, no precompiled headers, fastdebug
>> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update mallocLimit.hpp

Looks good, subject to addressing the minor issues already reported by others.
Leaving unapproved, but don't wait for my approval once you have others.

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

PR Review: https://git.openjdk.org/jdk/pull/19172#pullrequestreview-2053415755

From cjplummer at openjdk.org  Mon May 13 18:35:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 18:35:11 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <ja6gCoAx-hvhT_33lyZJv2IG2vhix3dE7uKO34jXa8Q=.a8a44872-a07c-4860-b6f4-818a26086458@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>
 <ja6gCoAx-hvhT_33lyZJv2IG2vhix3dE7uKO34jXa8Q=.a8a44872-a07c-4860-b6f4-818a26086458@github.com>
Message-ID: <A_rNhvniZIUp0EP2mbmcUgGGuXnJUztoqHGrIR6Opac=.451105c4-5f37-406e-b464-998eec3b6faa@github.com>

On Thu, 9 May 2024 21:40:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I guess there could be a race if one thread is destroying this monitor while another is trying to use it. Thus a thread could be doing something like a RawMonitorEnter in the middle of (or after) the monitor being destroyed. Fixing that would require holding dbgRawMonitor during RawMonitorEnter, and that would cause deadlocks all over the place. Also, this same potential issue exists already, but doesn't seem to ever arise. It seems we only call debugMonitorDestroy for cmdQueueLock. Not sure why that is.
>
> FWIW Deleting monitors is a tricky business and needs to be done with great care. You have to ensure all threads using the monitor are completely done with it. Simply locking it first to check it is "unused" is not sufficient.

This is probably the reason that the debug agent only destroys one of the 20 or so monitors it creates. I'm not sure how it got to that point. It may have destroyed more at one point but there were issues, and only one survived destruction without issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1598885045

From cjplummer at openjdk.org  Mon May 13 18:42:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 18:42:04 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v4]
In-Reply-To: <IyXLrjzsUBNtUS73pWWjVBrQtlC1UUL6-2Hv9FLZjcU=.8d9956a6-0643-434c-be5b-928f83491a66@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <kzYEUCr2-yqYgrr69DNOQxzcGFTWwBxY3Q3vvreqO60=.8e257972-dd26-48f7-a45b-ee0feb6aa5d8@github.com>
 <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com>
 <sOy1xVYrURz-5g3wOrKc09CKfnNSVahqm7U-XZDrYog=.9467c2e2-05b5-4c13-802f-05cc64c36e84@github.com>
 <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com>
 <MzhnF-PIi0mbK1OrgQLewN3_ug6g5lCswx3PR5QYrOI=.1411cc23-6e3f-4f75-ad93-8c624b846668@github.com>
 <ee_D6FTB_XTvV1huo2aH8Jsk1buNzTgASghvb3JfgKM=.4604d968-bd27-4e97-914c-bca7cd42126a@github.com>
 <WUP8RakvnBZpt_P1RrXANUFAoVSBbcm3H9M7tQ6ebxI=.96135dea-0c16-4afd-bc8a-09b3e014e6b9@github.com>
 <aPfayDrIDopF6Xnr6TkVa0h1eczmfMBQfBKQdPlKngw=.e73b5eaf-9cdd-438d-abd1-aee80aad3238@github.com>
 <diNCwQmM7ew9KsCbnle_k_SK8u0xuBOgRbUVffroEhM=.d13e2e28-bbb6-46c8-af56-f53a6a43f435@github.com>
 <tYmZtUV1qz1lDQLuGYgIKZVaAU9kvioo50_
 WSR9v4rI=.8fa6cb1f-0f17-4abf-b4d8-1ec46323bf32@github.com>
 <WNWRHYnzL83pF7CMvnhWd-5IQ-q8HhxuZXtA7tCMq8M=.1ea569af-9e37-4b21-bce3-26d798463d25@github.com>
 <IyXLrjzsUBNtUS73pWWjVBrQtlC1UUL6-2Hv9FLZjcU=.8d9956a6-0643-434c-be5b-928f83491a66@github.com>
Message-ID: <vZyRdilQORfglgruclLwqUs94H5gFBhTOxrfDos0ugg=.c04026fd-6caf-4983-89f8-cc7c0091d137@github.com>

On Thu, 9 May 2024 12:32:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> But 2 and 1 are very different. You can call them both leaf violations, but they are leaf violations for very different reasons, and 2 is more akin to a rank violation than a leaf violation.
>> 
>> I'm reversing the ranks and reworking the loop a bit (both the comments and how the errors are reported). I'll try to post later tonight after testing is done.
>
> This is updated function `assertOrderFailure()` to print "RANK ORDER" failure for the case #2 above:
> 
> static void
> assertOrderFailure(jthread thread,  DebugRawMonitorRank rank, DebugRawMonitor* dbg_monitor, char* msg)
> {
>     char* threadName = getThreadName(thread);
>      tty_message("DebugRawMonitor %s failure: (%s: %d > %d) for thread (%s)",
>                  msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);
> 
>      if (rank < FIRST_LEAF_DEBUG_RAW_MONITOR &&
>          dbg_monitor ->rank >= FIRST_LEAF_DEBUG_RAW_MONITOR) {
>          tty_message("DebugRawMonitor RANK ORDER failure: (%s: %d > %d) for thread (%s)",
>                      msg, dbg_monitor->name, dbg_monitor->rank, rank, threadName);
>      }
>      jvmtiDeallocate(threadName);
>      JDI_ASSERT(JNI_FALSE);
> }

I've given some more thought to this "leaf monitor" concept and decided it's not worth having around. The only thing that results in branding a monitor as a leaf monitor is the fact that no additional monitors are locked while the leaf monitor is held. This is not actually a requirement, but simply an observation made for these monitors. If any additional locking was introduced while holding a leaf monitor, that is not necessarily a bad thing. The list of leaf monitors is simply what was left over at the bottom of the rankings after all monitors that needed a higher rank were given one (and this was the result of an iterative process of running tests and seeing what asserts were triggered because of misranking some monitors). This list started out long, but after fixing all the rank issues we ended up with just 4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1598892053

From cjplummer at openjdk.org  Mon May 13 18:50:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 18:50:06 GMT
Subject: RFR: 8332098: Add missing `@since` tags to `jdk.jdi`
In-Reply-To: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
Message-ID: <mflDV_qVlQh7bbOjlXfAVKmclQg6PG6mkK23OF7FYT8=.a018623b-eb6d-4dcd-8092-a54339dc89e3@github.com>

On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple change where I add `@since` tags to the package-info file of the following packages
> ```com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
> 
> I used the unix `grep` command to find the oldest `@since` in each package and used that value, as it's hard to get the source code of JDK 1-5
> TIA

Can you fix the summary of the CR to not have backwards quotes. This seems to cause git some grief, as can be seen where the CR is mentioned in the Issue section of the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/19200#issuecomment-2108563473

From duke at openjdk.org  Mon May 13 19:30:31 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 19:30:31 GMT
Subject: RFR: 8332098: Add missing `@since` tags to `jdk.jdi` [v2]
In-Reply-To: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
Message-ID: <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>

> Please review this simple change where I add "@ since" tags to the package-info file of the following packages
> 
> com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
> 
> I used the unix grep command to find the oldest "@ since" in each package and used that value, as it's hard to get the source code of JDK 1-5
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  empty commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19200/files
  - new: https://git.openjdk.org/jdk/pull/19200/files/39b7ee70..2ec2b529

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

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

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

From duke at openjdk.org  Mon May 13 19:36:12 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 19:36:12 GMT
Subject: RFR: 8332098: Add missing `@since` tags to `jdk.jdi` [v2]
In-Reply-To: <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
 <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
Message-ID: <1wCm_qHoPttNXrg4W90CvvY9swvSC8H5-xK2pLp3Yso=.a5a3318d-8e1c-4045-a1e5-ee142001c728@github.com>

On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Please review this simple change where I add "@ since" tags to the package-info file of the following packages
>> 
>> com.sun.jdi
>> com.sun.jdi.connect
>> com.sun.jdi.connect.spi
>> com.sun.jdi.event
>> com.sun.jdi.request
>> 
>> I used the unix grep command to find the oldest "@ since" in each package and used that value, as it's hard to get the source code of JDK 1-5
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit

Done, I tend to use them for formatting.
And there are users with names such as "@ since" that would keep getting tagged.

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

PR Comment: https://git.openjdk.org/jdk/pull/19200#issuecomment-2108652386

From eastigeevich at openjdk.org  Mon May 13 20:37:40 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 20:37:40 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>
 <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>
Message-ID: <zUqDJO8r4145HB3NuUJfFqklmQCYVDhqb1bTWEIZL2g=.17159e9b-7003-4097-aa4d-ebcc9a0654cf@github.com>

On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> do you have tests which shows issues you listed in description?

Here is a jtreg test:

- `refresh_control.02.txt`

[
  {
    match: "serviceability.dcmd.compiler.DirectivesRefreshTest::callable",
    c2: {
      PrintOptoAssembly: true
    }
  }
]

- `DirectivesRefreshTest02.java`

/**
 * @test DirectivesRefreshTest02
 * @summary Test of forced recompile after compiler directives changes by diagnostic command
 * @requires vm.compiler1.enabled & vm.compiler2.enabled
 * @library /test/lib /
 * @modules java.base/jdk.internal.misc
 *
 * @build jdk.test.whitebox.WhiteBox
 * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
 *
 * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
 *                   -XX:+BackgroundCompilation -Xlog:codecache=trace -XX:-Inline -XX:+TieredCompilation -XX:CICompilerCount=2
 *                   -XX:+UnlockDiagnosticVMOptions
 *                   serviceability.dcmd.compiler.DirectivesRefreshTest02
 */

package serviceability.dcmd.compiler;

import jdk.test.whitebox.WhiteBox;

import jdk.test.lib.process.OutputAnalyzer;
import jdk.test.lib.dcmd.CommandExecutor;
import jdk.test.lib.dcmd.JMXExecutor;

import java.nio.file.Path;
import java.nio.file.Paths;
import java.lang.reflect.Method;
import java.util.Random;

import static jdk.test.lib.Asserts.assertEQ;

import static compiler.whitebox.CompilerWhiteBoxTest.COMP_LEVEL_NONE;
import static compiler.whitebox.CompilerWhiteBoxTest.COMP_LEVEL_SIMPLE;
import static compiler.whitebox.CompilerWhiteBoxTest.COMP_LEVEL_FULL_OPTIMIZATION;

public class DirectivesRefreshTest02 {

    static Path cmdPath = Paths.get(System.getProperty("test.src", "."), "refresh_control.02.txt");
    static WhiteBox wb = WhiteBox.getWhiteBox();
    static Random random = new Random();

    static Method method;
    static CommandExecutor executor;

    static int callable() {
        int result = 0;
        for (int i = 0; i < 100; i++) {
            result += random.nextInt(100);
        }
        return result;
    }

    static void setup() throws Exception {
        method = DirectivesRefreshTest.class.getDeclaredMethod("callable");
        executor = new JMXExecutor();

        wb.enqueueMethodForCompilation(method, COMP_LEVEL_SIMPLE);
        while (wb.isMethodQueuedForCompilation(method)) {
            Thread.onSpinWait();
        }
        wb.lockCompilation();
        boolean r = wb.enqueueMethodForCompilation(method, COMP_LEVEL_FULL_OPTIMIZATION);
        System.out.println("Method enqueued: " + r);
    }

    static void testDirectivesAddRefresh() {
        var output = executor.execute("Compiler.directives_add -r " + cmdPath.toString());
        output.stderrShouldBeEmpty().shouldContain("1 compiler directives added");
        System.out.println("Method enqueued: " + wb.isMethodQueuedForCompilation(method));
        wb.unlockCompilation();

        wb.enqueueMethodForCompilation(method, COMP_LEVEL_FULL_OPTIMIZATION);
        while (wb.isMethodQueuedForCompilation(method)) {
            Thread.onSpinWait();
        }
        System.out.println("Method compilation level: " + wb.getMethodCompilationLevel(method));

        assertEQ(true, false, "Stop here");
    }

    public static void main(String[] args) throws Exception {
        setup();
        testDirectivesAddRefresh();
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108744800

From cjplummer at openjdk.org  Mon May 13 20:37:43 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 20:37:43 GMT
Subject: RFR: 8332098: Add missing @ since tags to jdk.jdi [v2]
In-Reply-To: <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
 <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
Message-ID: <LZmyV940EEC9_81HsnIOzhEicMTr7B412jI4Hw0hFNc=.5315fc79-6fdf-4ac2-83a4-b218e10fbc4d@github.com>

On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Please review this simple change where I add "@ since" tags to the package-info file of the following packages
>> 
>> com.sun.jdi
>> com.sun.jdi.connect
>> com.sun.jdi.connect.spi
>> com.sun.jdi.event
>> com.sun.jdi.request
>> 
>> I used the unix grep command to find the oldest "@ since" in each package and used that value, as it's hard to get the source code of JDK 1-5
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19200#pullrequestreview-2053753720

From eastigeevich at openjdk.org  Mon May 13 20:40:49 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 20:40:49 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <QLM24t6iyGYE7oSVPZRLApLs0tFqHndcDjUrdsN1AFI=.85fbecc7-e9f3-41db-9d9a-36dcd3fab1a3@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

There is no `PrintOptoAssembly` in output.
I use `lockCompilation()`/`unlockCompilation()` to simulate:
> A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.

I think using them we can also simulate, though it would not be easy to write a test:
> JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108759073

From eastigeevich at openjdk.org  Mon May 13 20:50:01 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 20:50:01 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>
 <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>
Message-ID: <43tyZlzDKG1-M3YMBjjSKx2R3OosZuyfQySaBuV_KTc=.45597f64-6ff7-4d83-8416-aa29154d92df@github.com>

On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> How you found these issues?

I've been backporting JDK-8309271 to downstream 17 and 21. As compilations happens in background but a test from JDK-8309271 runs with background compilation off, I asked myself what might happen with background compilation. I have a patch fixing the test above. I don't think it is a complete fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108770472

From eastigeevich at openjdk.org  Mon May 13 21:11:02 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 13 May 2024 21:11:02 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

What if instead of backing out we will use an experimental JVM flag: `XX:+CompilerDirectivesRefreshSupport`?

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108802569

From amenkov at openjdk.org  Mon May 13 21:50:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 13 May 2024 21:50:04 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <A_rNhvniZIUp0EP2mbmcUgGGuXnJUztoqHGrIR6Opac=.451105c4-5f37-406e-b464-998eec3b6faa@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>
 <ja6gCoAx-hvhT_33lyZJv2IG2vhix3dE7uKO34jXa8Q=.a8a44872-a07c-4860-b6f4-818a26086458@github.com>
 <A_rNhvniZIUp0EP2mbmcUgGGuXnJUztoqHGrIR6Opac=.451105c4-5f37-406e-b464-998eec3b6faa@github.com>
Message-ID: <GUVeuqm29HkN1gG7pGGzYyUkgEdH6ePIBgC0_sV37KU=.bd11eb69-34da-4096-8aac-e14fad0ebc18@github.com>

On Mon, 13 May 2024 18:32:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> FWIW Deleting monitors is a tricky business and needs to be done with great care. You have to ensure all threads using the monitor are completely done with it. Simply locking it first to check it is "unused" is not sufficient.
>
> This is probably the reason that the debug agent only destroys one of the 20 or so monitors it creates. I'm not sure how it got to that point. It may have destroyed more at one point but there were issues, and only one survived destruction without issue.

If debugger attaches to the debuggee, detaches and re-attaches again, are the monitors recreated again?
(with rankedMonitor you added an assert if `DebugRawMonitor::monitor` is not null)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1599125113

From cjplummer at openjdk.org  Mon May 13 22:30:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 May 2024 22:30:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <GUVeuqm29HkN1gG7pGGzYyUkgEdH6ePIBgC0_sV37KU=.bd11eb69-34da-4096-8aac-e14fad0ebc18@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <Ur_FNcGflWwiFibdXZ94OwuV7UCz8-NxR5Jb488kRII=.012fa4a7-d278-4c09-8334-e1bb49aeb3ef@github.com>
 <ja6gCoAx-hvhT_33lyZJv2IG2vhix3dE7uKO34jXa8Q=.a8a44872-a07c-4860-b6f4-818a26086458@github.com>
 <A_rNhvniZIUp0EP2mbmcUgGGuXnJUztoqHGrIR6Opac=.451105c4-5f37-406e-b464-998eec3b6faa@github.com>
 <GUVeuqm29HkN1gG7pGGzYyUkgEdH6ePIBgC0_sV37KU=.bd11eb69-34da-4096-8aac-e14fad0ebc18@github.com>
Message-ID: <VMeS2AmMc36SO2E2Xwdd7w-WwRQFNS8TB99y5l3GJRw=.dfdfce9a-6275-4e09-8774-ab1943d58b84@github.com>

On Mon, 13 May 2024 21:47:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If debugger attaches to the debuggee, detaches and re-attaches again, are the monitors recreated again?
> (with rankedMonitor you added an assert if `DebugRawMonitor::monitor` is not null)

Almost all of the debugMonitorCreate() calls seem to come (indirectly) from initialize(), which is only called once.

cmdQueueLock, which is the one monitor we call debugMonitorDestroy() on, is called from debugLoop_run(), which is called whenever a debugger connection is initiated. This is the only case of creating, destroying, and then recreating. I wonder if there is some need for that.

popFrameEventLock and popFrameProceedLock are created lazily when first needed. There is a check to make sure they are not recreated if already created. They are never destroyed.

That seems to be it. So we pretty much create all monitors upon initialization and never recreate those that are created during initialization.

With regard to the assert, this can only be an issue for cmdQueueLock, and since  debugMonitorDestroy() is called on it (and that clears the needed fields), the assert shouldn't be triggered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1599160098

From kvn at openjdk.org  Mon May 13 22:46:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 May 2024 22:46:02 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <43tyZlzDKG1-M3YMBjjSKx2R3OosZuyfQySaBuV_KTc=.45597f64-6ff7-4d83-8416-aa29154d92df@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <SgqDOpSKyPqvmaaxGLP25agYqGJoqQ5AxqAhe3zo7PM=.dcf7ac03-9854-43c0-8015-f3e894ec52d2@github.com>
 <zHVquYy-oUb5phX787TJepF59prrpHjkII9aKLTd2S4=.5590ce39-dd05-47e7-a179-14ddfeea6988@github.com>
 <43tyZlzDKG1-M3YMBjjSKx2R3OosZuyfQySaBuV_KTc=.45597f64-6ff7-4d83-8416-aa29154d92df@github.com>
Message-ID: <dq_JHJmTF_HjA8yAIhQ4_658a3TX6z5QkZAcEt8MGjo=.4ad0ea20-5146-4a2b-9512-b0dd3b63f2a6@github.com>

On Mon, 13 May 2024 20:46:06 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> There is a race among a thread updating directives, compiler threads and CodeCache cleaning threads. We don't properly lock the directives stack, the compile queue and CodeCache to manage the race.

This is indeed concerning.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108925371

From kvn at openjdk.org  Mon May 13 22:46:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 May 2024 22:46:03 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>
Message-ID: <DGqvddzBgiYl40_MQVUeCz_bNLvNUNou_NtVI8eLSmg=.bb53afac-393d-4d11-b66f-76423a9e1140@github.com>

On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> What if instead of backing out we will use an experimental JVM flag: `XX:+CompilerDirectivesRefreshSupport`?

I don't think this is correct way to fix the bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2108926307

From kvn at openjdk.org  Mon May 13 22:52:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 May 2024 22:52:05 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <Ayb0p34ho0bcYSHIu4Sl2MCGQJXMBBcMJGOrQLQnSyQ=.167e42c8-d3fa-4c66-a687-104541cb29f7@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

I agree with this backout. Thank you @eastig  for explaining your point.
We have about 3 weeks before RDP1 and it is better we have less issues before that.
Let redo implementation in next release taking into account the issues you found and have more time for testing.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19215#pullrequestreview-2053940066

From jwaters at openjdk.org  Tue May 14 00:28:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 May 2024 00:28:05 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <d2qbMOw9E6lt7crXs3DHWdMx22NI7a8MKnSiIpUY7DI=.e68b0ed9-7f35-4e07-b08b-2fe7337c23cc@github.com>

On Thu, 9 May 2024 07:50:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Hmm, it seems Magnus isn't available at the moment. @erikj79 might you be able to answer my questions regarding hsdis?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2109049333

From duke at openjdk.org  Tue May 14 01:03:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 14 May 2024 01:03:09 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <wH9oXMHtE8zC39h51asmc0gpIjJVuYF6uah2-m5Nf2k=.db1cd4c5-8933-4ae2-ab50-d022636ba24b@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/prims/nativeLookup.cpp line 275:

> 273: 
> 274:   // Otherwise call static method findNative in ClassLoader
> 275: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 419:

> 417:   if (entry != nullptr) return entry;
> 418: 
> 419: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 426:

> 424:       return nullptr;
> 425:     }
> 426:   }

Suggestion:

  }

src/java.base/share/classes/java/lang/Module.java line 331:

> 329:                 String modflag = isNamed() ? getName() : "ALL-UNNAMED";
> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 System.err.printf("""

This?message should?probably be?different when?linking native?methods, since otherwise it?ll be:

WARNING: A restricted method in foo has been called
WARNING: bar has been called by Baz in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled


when?it?should really?be something?like:

WARNING: A JNI native method in foo has been linked
WARNING: bar has been linked in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for native methods in this module
WARNING: Native methods will be blocked in a future release unless native access is enabled

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248442
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248501
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248577
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599253428

From syan at openjdk.org  Tue May 14 02:16:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 14 May 2024 02:16:06 GMT
Subject: Integrated: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
In-Reply-To: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
Message-ID: <l9-P_3Cs-M5oEIgCJE87Pe1WCEhFVSPOlar8IKDTu40=.5058cb15-55f2-4471-b6a4-a477e73ea17f@github.com>

On Wed, 1 May 2024 14:14:22 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
> 
>   Only change the ProblemList, no risk.

This pull request has now been integrated.

Changeset: 440782e0
Author:    SendaoYan <syan at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/440782e0160f867f08afbec0abf48d557a522c72
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8331466: Problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

Reviewed-by: sspitsyn, cjplummer

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

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

From cjplummer at openjdk.org  Tue May 14 04:03:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 May 2024 04:03:02 GMT
Subject: RFR: 8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not
 mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC [v2]
In-Reply-To: <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
References: <k5evL-GFFoLLSxW68S9JzmzmRbuT8FltD2En_SLOCv8=.e869b6ec-9e24-497c-90e8-e421f65c22ba@github.com>
 <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
Message-ID: <oHuX2D_sg9HxD375DtVDmkJf83ItLdyK00SftP33bQc=.21b56eee-cb76-43a4-96da-7c63c9f4108d@github.com>

On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM options
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19224#pullrequestreview-2054228792

From syan at openjdk.org  Tue May 14 06:44:07 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 14 May 2024 06:44:07 GMT
Subject: RFR: 8331466: Problemlist
 serviceability/dcmd/gc/RunFinalizationTest.java on generic-all [v2]
In-Reply-To: <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
References: <ZWMmiOacof7UTOXeeHkbXn5sRTVfptOxuop1ffDzRVI=.fe5555f3-78b2-4b09-88d4-3efea087679c@github.com>
 <nkKSj-vjF9heYKE85Jw08A51D6E6KHzWMDp9vcupl98=.39397c57-33c8-4cc3-846f-a19851bcc5e6@github.com>
Message-ID: <IpVZ1GnqmFbVDXf1iTNv52uV2hV3-SHBimRbe9IiwfQ=.a1811fe7-33b8-4c4a-ad5e-c2bfb53d40e8@github.com>

On Wed, 8 May 2024 01:19:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>>   GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64.
>> 
>>   Only change the ProblemList, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

> /sponsor

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2109400393

From stuefe at openjdk.org  Tue May 14 07:01:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 07:01:03 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <jD8jfJeM_GyOvpD4K1VUuVCbaVdcbIZDrINJNoBA_Zw=.2d745cc5-3057-490d-9c03-05cb6c7ee778@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
 <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
 <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com>
 <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com>
 <jD8jfJeM_GyOvpD4K1VUuVCbaVdcbIZDrINJNoBA_Zw=.2d745cc5-3057-490d-9c03-05cb6c7ee778@github.com>
Message-ID: <AaG7Mp2WFHI0QhM5k9VujYhkgFqWk9mCAAU3opDT4Bc=.5ef7a60e-557f-41c8-99de-4379a081da73@github.com>

On Mon, 13 May 2024 15:48:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I tend to agree with that. My earlier question still stands: is there a better place to put it? Right now the "enforced with code" in a stand-alone file doesn't tell me "why" this rule is important.
>
> If you want to keep the static_assert it in the .cpp file, then I won't block that.

> Could you instead put the static_assert near the code that will break?

I like that. I will do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1599476559

From stuefe at openjdk.org  Tue May 14 07:01:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 07:01:03 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
 <pTStg0P42fAhcn47CxmRTyRElZpvEIbnLHTeJP9n5kc=.39b0265d-4610-4f9d-b426-967163267225@github.com>
 <mdPiV6VQ-6lZ9b7_B1AduBqe3EkUNH3JdqKPbO8KPpU=.b03dad27-6021-4874-90c2-75ff733eb4ae@github.com>
Message-ID: <7X2GeAXsh_ukEC7SeVR_U0VlLveqVb7qOrjrO0cK76U=.8db41eba-86fd-4943-b403-283b467f0392@github.com>

On Mon, 13 May 2024 14:47:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I don't feel like starting that particular bike shedding discussion :) But sure, sometime in the future we should do this. Here, I want it to be a simple renaming change.
>
> Right. That's why I prefixed this with "Open-ended comment/question", trying to make it super clear that it wasn't intended as a request for this PR, but rather a way to at least plant the seed of an idea that we might want to fix this eyesore.

I agree with you on the eyesore. 

MEMFLAGS does not follow any established convention, the implied plural is strange (its just one flag, not a set of), etc. We will change it sometime in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1599478327

From stuefe at openjdk.org  Tue May 14 07:19:32 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 07:19:32 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v3]
In-Reply-To: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
Message-ID: <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com>

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Feedback StefanK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19172/files
  - new: https://git.openjdk.org/jdk/pull/19172/files/42361558..2fc98923

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

  Stats: 41 lines in 4 files changed: 7 ins; 34 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19172/head:pull/19172

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

From stuefe at openjdk.org  Tue May 14 07:19:32 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 07:19:32 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v2]
In-Reply-To: <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <M4GfPaZ2ryq_1Q3rzFl_sWNYRWrLYQyAkkLdGGRLxq0=.1e17a602-ca47-4e49-a309-ad332e001a12@github.com>
 <eGF28oR9hMVbb2fvwFta6H84VKJePxslaq8EMwzsMFs=.3aa42eb7-df12-4cee-be52-0da6a7cbed5d@github.com>
Message-ID: <eVjoZyMfvBKh-F0HGfVbqJWBCw2BLomIu9kgVUhjreM=.6f81a3cc-0cc4-4966-b9ef-ceae6c319ac6@github.com>

On Mon, 13 May 2024 10:17:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update mallocLimit.hpp
>
> Changes requested by stefank (Reviewer).

@stefank New version, hopefully addressed all your remarks. Thanks!

> src/hotspot/share/nmt/memflags.cpp line 27:
> 
>> 25: #include "precompiled.hpp"
>> 26: 
>> 27: #include "nmt/memflags.hpp"
> 
> There should be no blankline between precompiled.hpp and the rest of the includes.

I removed the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/19172#issuecomment-2109454676
PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1599498716

From dholmes at openjdk.org  Tue May 14 07:51:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 May 2024 07:51:01 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't print summary during
 VM shutdown hook
In-Reply-To: <eHWcowHHgIRpeLhOYTx-Kbqi8uBiSMHXg2yO4OKKHqM=.3882612f-929e-4a99-8874-2d0ff2e19cb3@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
 <eHWcowHHgIRpeLhOYTx-Kbqi8uBiSMHXg2yO4OKKHqM=.3882612f-929e-4a99-8874-2d0ff2e19cb3@github.com>
Message-ID: <X3tJAeVCR4G1o4GX0K7ePCQTF7Ec5HfMQDwlPL8hZro=.9ed05223-2899-4c23-afc7-b8312b6fe97a@github.com>

On Mon, 13 May 2024 15:53:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Every log (as any Finalazible object) is registered using registerCleanup()

But you have changed Log so it is no longer a FinalizableObject. ?? Ah I see this is what you meant by disabling it. Now a Log is a plain old Java object with no special cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/19209#issuecomment-2109509115

From dholmes at openjdk.org  Tue May 14 08:42:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 May 2024 08:42:03 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't print summary during
 VM shutdown hook
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <MFgoqSpTDONT3M-wXyryS-WMuJyKRMa0LbapLWV6QUY=.03058dad-91d5-429d-a250-6f99cce1580b@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

Okay - seems fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19209#pullrequestreview-2054686733

From dholmes at openjdk.org  Tue May 14 09:59:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 May 2024 09:59:02 GMT
Subject: RFR: 8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not
 mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC [v2]
In-Reply-To: <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
References: <k5evL-GFFoLLSxW68S9JzmzmRbuT8FltD2En_SLOCv8=.e869b6ec-9e24-497c-90e8-e421f65c22ba@github.com>
 <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
Message-ID: <3LosTENVEPXiSEynSv-6wDNR_ces65ID9d0AuVJQ9MY=.b8481fb0-1c6c-4873-b538-f48240595863@github.com>

On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM options
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align

Updates look good.

FWIW the Java command reference doesn't mention the before/after full GC flags either.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19224#pullrequestreview-2054872345

From yyang at openjdk.org  Tue May 14 09:59:02 2024
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 14 May 2024 09:59:02 GMT
Subject: RFR: 8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not
 mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC [v2]
In-Reply-To: <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
References: <k5evL-GFFoLLSxW68S9JzmzmRbuT8FltD2En_SLOCv8=.e869b6ec-9e24-497c-90e8-e421f65c22ba@github.com>
 <QS_dYzc4ew3bpiQyje1pd2zMoWFDDRmswSOzt4jzOCU=.3271a6f4-d998-4287-a0c9-8f38afe0527f@github.com>
Message-ID: <FULMZP4VC_OfcNH-m5XrLypNmJrpfIpk5OczLkZOGl8=.cdf31c76-f828-4fa1-abd3-9ba51a363d4d@github.com>

On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM options
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align

Marked as reviewed by yyang (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19224#pullrequestreview-2054876579

From dchuyko at openjdk.org  Tue May 14 10:48:04 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Tue, 14 May 2024 10:48:04 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>
Message-ID: <QhVbiHxngrcUlohiysiwELi17mI9L40SUhePaF0vRtw=.a7a2b3f8-4c70-441f-8c4c-e38fa4e38745@github.com>

On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
>> 
>> Found bugs:
>> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
>> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
>> 
>> There are other concerns: bugs and performance issues.
>> 
>> Possible bugs:
>> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
>> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
>> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
>> 
>> Performance issues:
>> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
>> 
>> The backout is not clean because of removal of `CompiledMethod`.
>> 
>> Tested with release and fastdebug builds: tier1  and tier2 passed.
>
> What if instead of backing out we will use an experimental JVM flag: `XX:+CompilerDirectivesRefreshSupport`?

> I agree with this backout. Thank you @eastig for explaining your point. We have about 3 weeks before RDP1 and it is better we have less issues before that. Let redo implementation in next release taking into account the issues you found and have more time for testing.

OK. I hope it takes less time to get back into the source tree than it did initially.

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2109874596

From stefank at openjdk.org  Tue May 14 14:50:04 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 May 2024 14:50:04 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v3]
In-Reply-To: <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com>
Message-ID: <E8NwDd-AJud5fFfsVVE_A_zUOdpUdIipqFRQybZ9qhI=.c0239d49-a220-4a83-a0f4-9973f4d47c0e@github.com>

On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> MEMFLAGS, as well as its enum constants, should live in its own include. 
>> 
>> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
>> 
>> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
>> 
>> ---
>> 
>> This patch moves the enum to its new file.
>> 
>> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
>> 
>> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
>> 
>> I tested (built) on:
>> - MacOS aarch64, no precompiled headers, fastdebug
>> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback StefanK

Looks good. Thanks!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19172#pullrequestreview-2055637663

From stuefe at openjdk.org  Tue May 14 15:02:11 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 15:02:11 GMT
Subject: RFR: 8332042: Move MEMFLAGS to its own include file [v3]
In-Reply-To: <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
 <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com>
Message-ID: <oy-dhemCFJqtxOvyLdWWIAaVoTnvVwG2PzebbMrxaOY=.627c49e8-6fa2-486b-842d-bb8c17069dd2@github.com>

On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> MEMFLAGS, as well as its enum constants, should live in its own include. 
>> 
>> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
>> 
>> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
>> 
>> ---
>> 
>> This patch moves the enum to its new file.
>> 
>> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
>> 
>> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
>> 
>> I tested (built) on:
>> - MacOS aarch64, no precompiled headers, fastdebug
>> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback StefanK

Thanks @afshin-zafari @stefank @kimbarrett @jdksjolen

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

PR Comment: https://git.openjdk.org/jdk/pull/19172#issuecomment-2110464347

From stuefe at openjdk.org  Tue May 14 15:02:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 15:02:12 GMT
Subject: Integrated: 8332042: Move MEMFLAGS to its own include file
In-Reply-To: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
References: <ucUpx3JpyNGPTvW-sveZpHOE_XaMDrh8ZJSPsdgho_0=.c2c380a7-35df-481a-9d61-b9755716aa1f@github.com>
Message-ID: <q1DYiUx5rALP0EYqbta8TUw1L8yspfzXI4zvtKOHUxQ=.e32dd292-ae8a-4f54-afe2-00a80e00ed59@github.com>

On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

This pull request has now been integrated.

Changeset: 95a60131
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95a601316de06b4b0fbf6e3c7777be5d2a1ca978
Stats:     201 lines in 25 files changed: 99 ins; 66 del; 36 mod

8332042: Move MEMFLAGS to its own include file

Reviewed-by: jsjolen, stefank

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

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

From cjplummer at openjdk.org  Tue May 14 17:54:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 May 2024 17:54:05 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
 <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
 <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>
Message-ID: <TA_0MV0DCHOLAFq2qDgqnPP5TvM-iFhg-kOOEXhgVBo=.d1945995-7e66-44b6-941b-b02a156df800@github.com>

On Fri, 3 May 2024 10:42:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> ...and there are also comments above with this issue.
>
>> expEnteringCount/expWaitingCount contain the tested patterns.
> 
> I kind of disagree.
> Please, take look at the loop below:
> 
>             for (int i = 0; i < NUMBER_OF_WAITING_THREADS; i++) {
>                 expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS + i + 1;
>                 expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS - i - 1;
>                 lockCheck.notify(); // notify waiting threads one by one
>                 // now the notified WaitingTask has to be blocked on the lockCheck re-enter
> 
>                 // entry count: 1
>                 // count of threads waiting to enter:       NUMBER_OF_ENTERING_THREADS
>                 // count of threads waiting to re-enter:    i + 1
>                 // count of threads waiting to be notified: NUMBER_OF_WAITING_THREADS - i - 1
>                 check(lockCheck, expOwnerThread(), expEntryCount(),
>                       expEnteringCount,
>                       expWaitingCount);
>             }
> 
> The comment fixed as you suggest does not look useful anymore as the tested pattern is lost:
> 
>                 // entry count: expOwnerThread()
>                 // count of threads waiting to enter:       expEnteringCount
>                 // count of threads waiting to re-enter:   expEntryCount()
>                 // count of threads waiting to be notified: expWaitingCount
>                 check(lockCheck, expOwnerThread(), expEntryCount(),
>                       expEnteringCount,
>                       expWaitingCount);
>             }
> 
> 
> I understand your concern but your suggestion is not that good.
> We could remove these comments but the tested pattern will be thrown away with the comments.
> Would it help if we add clarifications that the comments are correct for platform threads only?

I don't understand the issue with the updated commented. It is precisely telling you what the expected "count" values should be. If you leave the macros in the comment, then the comment is wrong for virtual threads. If you want to keep the macros in the comment, you need to add something like "... or 0 for virtual threads".

BTW, the "re-enter" comment should continue to be "i + 1". I'm not sure why it was changed to "expEntryCount()".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1600436569

From mcimadamore at openjdk.org  Tue May 14 18:10:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 May 2024 18:10:28 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/bad10942..0d21bf99

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

  Stats: 84 lines in 15 files changed: 42 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

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

From cjplummer at openjdk.org  Tue May 14 20:12:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 May 2024 20:12:03 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't print summary during
 VM shutdown hook
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <y_fo1fsEr4j1BKC8ptLxA4kkjdHnaqjp5WjssaIx9cM=.e4d39a90-0655-4eca-8e49-5eccdc90b8d3@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

Copyrights needs updating.

test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 587:

> 585:      * print a warning message first.
> 586:      */
> 587:     private synchronized void printErrorsSummary() {

There is a comment above that still references this method.

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

PR Review: https://git.openjdk.org/jdk/pull/19209#pullrequestreview-2056296736
PR Review Comment: https://git.openjdk.org/jdk/pull/19209#discussion_r1600577870

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <dyGsHe50-9tsvxAgjvkSEgeMxpWfBIcxbHry9HXI3MI=.3bf65598-5584-4794-a502-3e0925fe1710@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Withdrawing this, as a different approach is required.

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2111182078

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: Withdrawn: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <3IfStE5WvNR62yu4s0sbkQWZ9TWw3UIrXILYhrHdlc4=.dcfd1934-f44f-4f79-9fb6-4b87bd6679ea@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This pull request has been closed without being integrated.

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

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

From lmesnik at openjdk.org  Tue May 14 22:19:19 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 14 May 2024 22:19:19 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't print summary during
 VM shutdown hook [v2]
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <_SHejzXr7Vq7lwN3XI9-a1ZXsyfKrULFfPVHruXAGkQ=.672bceab-a5fa-4664-9030-dee17113aafc@github.com>

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

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

  fixed after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19209/files
  - new: https://git.openjdk.org/jdk/pull/19209/files/68b20e65..69ffd5b7

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

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

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

From cjplummer at openjdk.org  Tue May 14 22:36:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 May 2024 22:36:01 GMT
Subject: RFR: 8332112: Update nsk.share.Log to don't print summary during
 VM shutdown hook [v2]
In-Reply-To: <_SHejzXr7Vq7lwN3XI9-a1ZXsyfKrULFfPVHruXAGkQ=.672bceab-a5fa-4664-9030-dee17113aafc@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
 <_SHejzXr7Vq7lwN3XI9-a1ZXsyfKrULFfPVHruXAGkQ=.672bceab-a5fa-4664-9030-dee17113aafc@github.com>
Message-ID: <Fy8BlS6sB4Zon9N_CZZT0g8eRGmdr8XAg-gqiXTjx5k=.fd2a9daf-c505-492f-a233-4bd3ed1b4fa7@github.com>

On Tue, 14 May 2024 22:19:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
>> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
>> 
>> The cleanup() method flush stream and print summary which should be already printed by complain method.
>> 
>> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
>> 
>> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
>> 
>> Note: The 'verboseOnErrorEnabled' is just not used.
>> 
>> See isVerboseOnErrorEnabled.
>> 
>>     public boolean isVerboseOnErrorEnabled() {
>>         return errorsSummaryEnabled;
>>     }
>> 
>> 
>> Tested with by running tests with different combinations (tier4-7) and tier1.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed after comments

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19209#pullrequestreview-2056579895

From sspitsyn at openjdk.org  Tue May 14 23:16:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 May 2024 23:16:02 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <TA_0MV0DCHOLAFq2qDgqnPP5TvM-iFhg-kOOEXhgVBo=.d1945995-7e66-44b6-941b-b02a156df800@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
 <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
 <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>
 <TA_0MV0DCHOLAFq2qDgqnPP5TvM-iFhg-kOOEXhgVBo=.d1945995-7e66-44b6-941b-b02a156df800@github.com>
Message-ID: <EhEXq-iCKcsm83qhYqVP5r4XiVtUy7_5kGEKyc6Q61E=.ead998c3-bcd6-4b28-9d52-bb6941854d0b@github.com>

On Tue, 14 May 2024 17:51:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> expEnteringCount/expWaitingCount contain the tested patterns.
>> 
>> I kind of disagree.
>> Please, take look at the loop below:
>> 
>>             for (int i = 0; i < NUMBER_OF_WAITING_THREADS; i++) {
>>                 expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS + i + 1;
>>                 expWaitingCount  = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS - i - 1;
>>                 lockCheck.notify(); // notify waiting threads one by one
>>                 // now the notified WaitingTask has to be blocked on the lockCheck re-enter
>> 
>>                 // entry count: 1
>>                 // count of threads waiting to enter:       NUMBER_OF_ENTERING_THREADS
>>                 // count of threads waiting to re-enter:    i + 1
>>                 // count of threads waiting to be notified: NUMBER_OF_WAITING_THREADS - i - 1
>>                 check(lockCheck, expOwnerThread(), expEntryCount(),
>>                       expEnteringCount,
>>                       expWaitingCount);
>>             }
>> 
>> The comment fixed as you suggest does not look useful anymore as the tested pattern is lost:
>> 
>>                 // entry count: expOwnerThread()
>>                 // count of threads waiting to enter:       expEnteringCount
>>                 // count of threads waiting to re-enter:   expEntryCount()
>>                 // count of threads waiting to be notified: expWaitingCount
>>                 check(lockCheck, expOwnerThread(), expEntryCount(),
>>                       expEnteringCount,
>>                       expWaitingCount);
>>             }
>> 
>> 
>> I understand your concern but your suggestion is not that good.
>> We could remove these comments but the tested pattern will be thrown away with the comments.
>> Would it help if we add clarifications that the comments are correct for platform threads only?
>
> I don't understand the issue with the updated commented. It is precisely telling you what the expected "count" values should be. If you leave the macros in the comment, then the comment is wrong for virtual threads. If you want to keep the macros in the comment, you need to add something like "... or 0 for virtual threads".
> 
> BTW, the "re-enter" comment should continue to be "i + 1". I'm not sure why it was changed to "expEntryCount()".

Okay, please, let me explain this one more time.
The original comments before method `check()` calls describe the testing scenario but not the numbers expected to be returned by the JVMTI `GetObjectMonitorUsage`.
For instance, if the testing scenario says: "count of threads waiting to enter: NUMBER_OF_ENTERING_THREADS" then it means there is a real number of these threads waiting to enter the monitor. And it does not matter if they are platform or virtual threads. They are really waiting to enter the monitor. However, the JVMTI `GetObjectMonitorUsage` won't include virtual threads into the returned results.

Now, I'm suggesting to add the following header for comments before each `check()` method call:

+            // The numbers below describe the testing scenario, not the expected results.
+            // The expected numbers are different for virtual threads because
+            // they are not supported by JVMTI GetObjectMonitorUsage.

Would it work for you?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1600769143

From sspitsyn at openjdk.org  Tue May 14 23:22:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 May 2024 23:22:03 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <EhEXq-iCKcsm83qhYqVP5r4XiVtUy7_5kGEKyc6Q61E=.ead998c3-bcd6-4b28-9d52-bb6941854d0b@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
 <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
 <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>
 <TA_0MV0DCHOLAFq2qDgqnPP5TvM-iFhg-kOOEXhgVBo=.d1945995-7e66-44b6-941b-b02a156df800@github.com>
 <EhEXq-iCKcsm83qhYqVP5r4XiVtUy7_5kGEKyc6Q61E=.ead998c3-bcd6-4b28-9d52-bb6941854d0b@github.com>
Message-ID: <pMASnhPKhly_qC7Li9xIqAUAAihJrUgCQLwy0uYQaSA=.03ba9dcf-0b83-4b97-9653-bb4304909451@github.com>

On Tue, 14 May 2024 23:13:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I don't understand the issue with the updated commented. It is precisely telling you what the expected "count" values should be. If you leave the macros in the comment, then the comment is wrong for virtual threads. If you want to keep the macros in the comment, you need to add something like "... or 0 for virtual threads".
>> 
>> BTW, the "re-enter" comment should continue to be "i + 1". I'm not sure why it was changed to "expEntryCount()".
>
> Okay, please, let me explain this one more time.
> The original comments before method `check()` calls describe the testing scenario but not the numbers expected to be returned by the JVMTI `GetObjectMonitorUsage`.
> For instance, if the testing scenario says: "count of threads waiting to enter: NUMBER_OF_ENTERING_THREADS" then it means there is a real number of these threads waiting to enter the monitor. And it does not matter if they are platform or virtual threads. They are really waiting to enter the monitor. However, the JVMTI `GetObjectMonitorUsage` won't include virtual threads into the returned results.
> 
> Now, I'm suggesting to add the following header for comments before each `check()` method call:
> 
> +            // The numbers below describe the testing scenario, not the expected results.
> +            // The expected numbers are different for virtual threads because
> +            // they are not supported by JVMTI GetObjectMonitorUsage.
> 
> Would it work for you?

> BTW, the "re-enter" comment should continue to be "i + 1".
> I'm not sure why it was changed to "expEntryCount()".

It depends on what are we trying to describe. We either describe the testing scenario (the number of threads doing something) or the expected results. I understood that you wanted to describe the results instead of the scenario. And then it becomes problematic to do so as you can see.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1600772051

From sspitsyn at openjdk.org  Tue May 14 23:52:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 May 2024 23:52:07 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <sF24teBZ59vbwasns9jG3Bd6qNO2MD04fqBaT2h-rL4=.3cbee8f2-a6a8-4952-b04a-143e87155348@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <sF24teBZ59vbwasns9jG3Bd6qNO2MD04fqBaT2h-rL4=.3cbee8f2-a6a8-4952-b04a-143e87155348@github.com>
Message-ID: <CtwZFx0EmBPofVUIJtoIqiQtE9Av-DUxbYR9X4wPt0U=.d6b2a620-1501-457b-83b4-5f75f1b9fa63@github.com>

On Thu, 2 May 2024 21:50:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/java.se/share/data/jdwp/jdwp.spec line 1622:
>> 
>>> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
>>> 1621:                                 "if owned` by a virtual thread or not owned.")
>>> 1622:             (int entryCount "The number of times the owning platform thread has entered the monitor.")
>> 
>> See the comment I left for the JVMTI spec. We should be more complete in the explanation here, explaining how it is 0 for virtual threads.
>
> I don't think this has been resolved.

Okay, thanks! Fixed now. The update is:

--- a/src/java.se/share/data/jdwp/jdwp.spec
+++ b/src/java.se/share/data/jdwp/jdwp.spec
@@ -1619,9 +1619,11 @@ JDWP "Java(tm) Debug Wire Protocol"
         (Reply
             (threadObject owner "The platform thread owning this monitor, or null "
                                 "if owned by a virtual thread or not owned.")
-            (int entryCount "The number of times the owning platform thread has entered the monitor.")
+            (int entryCount "The number of times the owning platform thread has entered the monitor, "
+                            "or 0 if owned by a virtual thread or not owned.")
             (Repeat waiters "The total number of platform threads that are waiting to enter or re-enter "
-                            "the monitor, or waiting to be notified by the monitor."
+                            "the monitor, or waiting to be notified by the monitor, or 0 if "
+                            "only virtual threads are waiting or no threads are waiting."
                 (threadObject thread "A platform thread waiting for this monitor.")
             )
         )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1600779564

From sspitsyn at openjdk.org  Tue May 14 23:52:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 May 2024 23:52:09 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v3]
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <HsFFi7tdbKgocSQm3t16Y_G7_Q8xZXjDUcWn6QobbEE=.64eb5985-c356-4125-a10f-f9e7d69970ac@github.com>

On Wed, 1 May 2024 20:45:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweaks in JVMTI and JDWP changes
>
> src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 348:
> 
>> 346:     /**
>> 347:      * Returns a List containing a {@link ThreadReference} for
>> 348:      * each platform thread currently waiting for this object's monitor.
> 
> You need to add "platform" a little below in the `@return` section.

Okay, thanks! Fixed now. The update is:

diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java b/src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java
index 3f3490e84cd..affbf9f6c4c 100644
--- a/src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java
+++ b/src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java
@@ -355,7 +355,8 @@ Value invokeMethod(ThreadReference thread, Method method,
      * operation is supported.
      *
      * @return a List of {@link ThreadReference} objects. The list
-     * has zero length if no threads are waiting for the monitor.
+     * has zero length if no threads are waiting for the monitor,
+     * or only virtual threads are waiting for the monitor.
      * @throws java.lang.UnsupportedOperationException if the
      * target VM does not support this operation.
      * @throws IncompatibleThreadStateException if any

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1600786965

From sspitsyn at openjdk.org  Tue May 14 23:56:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 May 2024 23:56:14 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/e7c2d652..8438cf4a

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

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

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

From nizar.benalla at oracle.com  Wed May 15 00:13:16 2024
From: nizar.benalla at oracle.com (Nizar Benalla)
Date: Wed, 15 May 2024 00:13:16 +0000
Subject: Converting existing package.html files to package-info.java
Message-ID: <BL3PR10MB618653272EB340661F4CA1978AE32@BL3PR10MB6186.namprd10.prod.outlook.com>

Hello,

I discovered after some recent work around javadoc that `javac` does not recognize `package.html` files, which predate `package-info.java`. Some tools that want to analyze doc comments need to deal with this in special ways.

Maybe optional support for these files can be added into `javac`. But with only 21 `package.html` files in the JDK in modules that do not have internal in the name, I want to suggest simply converting them as it will be done once and won't need maintenance

There are 9 package.html files I'd like to convert into package-info.java in java.management, one in java.management.rmi (and if this passes, one in java.naming)

I want to hear what you think,
Nizar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240515/b15d0ebd/attachment-0001.htm>

From dholmes at openjdk.org  Wed May 15 01:04:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:01 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <Nug6-9W3vYrLZVsbSccwpBqVwwzzWuThfLrA-JOjh5Y=.6dc93c53-8683-4b56-a550-cdf6a7928bf2@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

Hotspot changes look good - notwithstanding discussion about properlty namespace placement. Manpage changes also look good.

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

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2056696636

From dholmes at openjdk.org  Wed May 15 01:04:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
Message-ID: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>

On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix another typo
>>  - Fix typo
>>  - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line 2271:
> 
>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>> 2271:         return JNI_ENOMEM;
> 
> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1600819327

From sspitsyn at openjdk.org  Wed May 15 06:03:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 06:03:07 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <uW1YBI63VbidNq3eAkOQFUfxOsHFW_ZOTkyWW4IYCrE=.1dda1260-31b0-480a-9d53-cff2b7506ad0@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
 <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
 <OySW23RnwQQOK1Dl721B1uHiculZ6Qx-l0sNm5gRl7E=.7ffd070e-1f0d-4f2a-bbf3-5f7dcbe520b0@github.com>
 <uW1YBI63VbidNq3eAkOQFUfxOsHFW_ZOTkyWW4IYCrE=.1dda1260-31b0-480a-9d53-cff2b7506ad0@github.com>
Message-ID: <vZMxz_pv7Q6MV3YGDoBfTeUQQvFzMrXEFLHZzgtpjbQ=.e4429b55-c4e7-4314-acb0-da7d34c4d356@github.com>

On Fri, 10 May 2024 22:09:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Perhaps this is not what Chris had in mind, but I'm wondering what happens in some
> Thread-A when it is checked and passed by but then Thread-A sets the flag in itself
> after the for-loop has passed it by. Does that Thread-A flag value get lost?

Thank you for the question.
The Thread-A sets the flag optimistically and then re-checks if `sync_protocol_enabled()` and any disabler exists. It can be global disbaler (`_VTMS_transition_disable_for_all_count > 0`) or disabler of `Thread-A` only (`java_lang_Thread::VTMS_transition_disable_count(vth()) > 0`). If any disabler exists then `Thread-A` clears the optimistic settings and goes with the pessimistic approach under protection of `JvmtiVTMSTransition_lock`.

Please, let me know if you still have questions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1600987604

From jpai at openjdk.org  Wed May 15 06:05:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 15 May 2024 06:05:13 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests are not compatible with jtreg test
 factory
Message-ID: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>

Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?

These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.

That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.

The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.

I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

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

Commit messages:
 - 8307778: com/sun/jdi/cds tests are not compatible with jtreg test factory

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

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

From alanb at openjdk.org  Wed May 15 06:18:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 06:18:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
Message-ID: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>

On Wed, 15 May 2024 00:54:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2271:
>> 
>>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>>> 2271:         return JNI_ENOMEM;
>> 
>> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.
>
> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601002132

From dholmes at openjdk.org  Wed May 15 06:24:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 06:24:01 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests are not compatible with jtreg
 test factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <BoBhMh6lcx4GxMJziDoeJnHYNR_ajabm_M2O8QCovh8=.a6964496-cb7e-406e-ac7c-24b7b2b022c4@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

Looks good.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19244#pullrequestreview-2056988315

From sspitsyn at openjdk.org  Wed May 15 07:52:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 07:52:02 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests are not compatible with jtreg
 test factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <9DAxT7CKkwfO--15Kj-GliNuij4f8oQuijqtdxaG-3k=.50b04ca8-07ce-44ae-afdc-01e3b31d9344@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19244#pullrequestreview-2057187138

From duke at openjdk.org  Wed May 15 07:59:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 07:59:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

src/java.base/share/classes/java/lang/Module.java line 334:

> 332:                     System.err.printf("""
> 333:                             WARNING: A native method in %s has been bound
> 334:                             WARNING: %s has been called by %s in %s

Note that this line is still not entirely correct, as for code like:

// in module a:
package a;

import b.Foo;

public class Foo {
	public static void main(String... args) {
		System.load("JNI library implementing Java_b_Bar_nativeMethod");

		Bar.nativeMethod();
	}
}


// in module b:
package b;

public class Bar {
	public static native void nativeMethod();
}


It?ll?show?`Bar` as?the?caller of?`Bar::nativeMethod()`, even?though the?caller is?`Foo` in?this?case, which?is?why I?initially?suggested just?omitting the?caller from?**JNI** linkage?warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601140578

From magnus.ihse.bursie at oracle.com  Wed May 15 08:16:19 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 15 May 2024 10:16:19 +0200
Subject: Converting existing package.html files to package-info.java
In-Reply-To: <BL3PR10MB618653272EB340661F4CA1978AE32@BL3PR10MB6186.namprd10.prod.outlook.com>
References: <BL3PR10MB618653272EB340661F4CA1978AE32@BL3PR10MB6186.namprd10.prod.outlook.com>
Message-ID: <976849d3-3c0e-4ea3-be6f-f549761bdc9d@oracle.com>

On 2024-05-15 02:13, Nizar Benalla wrote:

> Hello,
>
> I discovered after some recent work around javadoc that `javac` does 
> not recognize `package.html` files, which predate `package-info.java`. 
> Some tools that want to analyze doc comments need to deal with this in 
> special ways.
>
> Maybe optional support for these files can be added into `javac`. But 
> with only 21 `package.html` files in the JDK in modules that do not 
> have internal in the name, I want to suggest simply converting them as 
> it will be done once and won't need maintenance
>
> There are 9 package.html files I'd like to convert into 
> package-info.java in java.management, one in java.management.rmi (and 
> if this passes, one in java.naming)
>
> I want to hear what you?think,
> Nizar
>
That sounds like a straightforward and beneficial conversion. As you 
say, the package.html format is old, and provides no benefits to 
package-info.java.


/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240515/53d7b0a9/attachment.htm>

From Alan.Bateman at oracle.com  Wed May 15 08:19:11 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 May 2024 09:19:11 +0100
Subject: Converting existing package.html files to package-info.java
In-Reply-To: <976849d3-3c0e-4ea3-be6f-f549761bdc9d@oracle.com>
References: <BL3PR10MB618653272EB340661F4CA1978AE32@BL3PR10MB6186.namprd10.prod.outlook.com>
 <976849d3-3c0e-4ea3-be6f-f549761bdc9d@oracle.com>
Message-ID: <3d9049e6-6177-4b01-b190-4bdf4e2959eb@oracle.com>



On 15/05/2024 09:16, Magnus Ihse Bursie wrote:
>
> On 2024-05-15 02:13, Nizar Benalla wrote:
>
>> Hello,
>>
>> I discovered after some recent work around javadoc that `javac` does 
>> not recognize `package.html` files, which predate 
>> `package-info.java`. Some tools that want to analyze doc comments 
>> need to deal with this in special ways.
>>
>> Maybe optional support for these files can be added into `javac`. But 
>> with only 21 `package.html` files in the JDK in modules that do not 
>> have internal in the name, I want to suggest simply converting them 
>> as it will be done once and won't need maintenance
>>
>> There are 9 package.html files I'd like to convert into 
>> package-info.java in java.management, one in java.management.rmi (and 
>> if this passes, one in java.naming)
>>
>> I want to hear what you?think,
>> Nizar
>>
> That sounds like a straightforward and beneficial conversion. As you 
> say, the package.html format is old, and provides no benefits to 
> package-info.java.
>
>
I agree. There was an effort a few years ago to replace html package 
descriptions with package-info.java but it seems that a few of them 
weren't done at the time.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240515/57ed19f7/attachment-0001.htm>

From mcimadamore at openjdk.org  Wed May 15 09:59:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 09:59:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
 <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
Message-ID: <_MDZPWLFa7qcrmsqMsXDJx6Y5lqfI3E4d6Z6-VKv79g=.ad216d38-b066-47d2-bfcd-31a64052015d@github.com>

On Wed, 15 May 2024 07:55:27 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note that this line is still not entirely correct, as for code like:

You are correct - the message is however consistent with what written in JEP 472. I'll discuss with @pron

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601335120

From eastigeevich at openjdk.org  Wed May 15 09:59:11 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 15 May 2024 09:59:11 GMT
Subject: RFR: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <DGqvddzBgiYl40_MQVUeCz_bNLvNUNou_NtVI8eLSmg=.bb53afac-393d-4d11-b66f-76423a9e1140@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
 <UjFbTiOB8sAriDZPETdbzWu4rG9ksYK1euTn4IUvUZ4=.fdae1dbf-57f1-412b-b287-bea1d96ee70a@github.com>
 <DGqvddzBgiYl40_MQVUeCz_bNLvNUNou_NtVI8eLSmg=.bb53afac-393d-4d11-b66f-76423a9e1140@github.com>
Message-ID: <sV2Yz_OYPmZy2pjKgJkAWIHAdqMKd-2oZtka_NbOrb0=.cd0d6333-2e64-43d4-8ae5-0c640b314703@github.com>

On Mon, 13 May 2024 22:43:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> What if instead of backing out we will use an experimental JVM flag: `XX:+CompilerDirectivesRefreshSupport`?
>
>> What if instead of backing out we will use an experimental JVM flag: `XX:+CompilerDirectivesRefreshSupport`?
> 
> I don't think this is correct way to fix the bug.

Thank you, @vnkozlov @dchuyko @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/19215#issuecomment-2112072984

From eastigeevich at openjdk.org  Wed May 15 09:59:12 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 15 May 2024 09:59:12 GMT
Subject: Integrated: 8332111: [BACKOUT] A way to align already compiled methods
 with compiler directives
In-Reply-To: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
References: <y_nZCN3tWKBB-fietFmkKpNGVol8JeM-0chOfu5plG4=.372cc7e6-ef0f-4bcd-ad6f-0712d1704051@github.com>
Message-ID: <qjoxgmMPeElaqxtBawPXAs_f-bZQ6M0Uw2WjEyInRV4=.5aacdfc0-ecdb-4169-bc94-a7d87cb48326@github.com>

On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which has known bugs, possible bugs and performance issues. REDO work is tracked by [JDK-8331749](https://bugs.openjdk.org/browse/JDK-8331749).
> 
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call `DirectivesStack::hasMatchingDirectives(mh, true)` which only considers the compiler directive which is on the top of the directives stack. As more than one directive can be added, `CompilerDirectivesAddDCmd::execute` will not behave as expected.
> - A Java method with old directives might be in the compilation queue. A request to recompile it with new directives will be ignored.
> 
> There are other concerns: bugs and performance issues.
> 
> Possible bugs:
> - `has_matching_directives` might not be cleared. A nmethod might get into the unloading state before `CodeCache::recompile_marked_directives_matches`. If the nmethod has been used to mark a Java method and it is the only nmethod, there will be no nmethod in CodeCache to reach the Java method to clear the mark.
> - A Java method might have been compiled with new directives before `CodeCache::recompile_marked_directives_matches`. `CodeCache::recompile_marked_directives_matches` will recompile it again.
> - JIT compiler might be compiling a Java method with old directives. A request to recompile it with new directives will be ignored.
> 
> Performance issues:
> - Usually directives are updated for a small number of Java methods. If CodeCache has thousands of nmethods, `CodeCache::recompile_marked_directives_matches` will be traversing nmethods most of which don't need recompilation.
> 
> The backout is not clean because of removal of `CompiledMethod`.
> 
> Tested with release and fastdebug builds: tier1  and tier2 passed.

This pull request has now been integrated.

Changeset: 1a944478
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a944478a26a766f5a573a1236b642d8e7b0685c
Stats:     380 lines in 15 files changed: 3 ins; 347 del; 30 mod

8332111: [BACKOUT] A way to align already compiled methods with compiler directives

Reviewed-by: shade, kvn

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

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

From mcimadamore at openjdk.org  Wed May 15 10:37:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:37:24 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
Message-ID: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>

On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?
>
> That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601386336

From mcimadamore at openjdk.org  Wed May 15 10:40:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:40:34 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v5]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Refine warning text for JNI method binding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/0d21bf99..daf729f4

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

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

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

From alanb at openjdk.org  Wed May 15 11:05:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 11:05:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
 <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
Message-ID: <DLv_q_jPw8OfE2JXGhq-Fk_y3HAET55Fl8as0LvO7zo=.ee2d56a3-aee4-45e7-8bc3-b8ef89778480@github.com>

On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

It maps here to a jdk.module.* property so I suppose it's okay. The functions were introduced to create jdk.module.* properties where the values were a set module names or a module path. Maybe these functions should be renamed at some point (not here) as they are more widely useful now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601421535

From jwaters at openjdk.org  Wed May 15 13:08:14 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 May 2024 13:08:14 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <G-d5bIKoJ6s9_HLHlFrrKGMACGf8m643U6V_dhPcAiE=.967a2ec8-da86-4aea-b10f-0fa4b1762536@github.com>

On Thu, 9 May 2024 07:50:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Magnus? Erik? You guys there? :(

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2112465392

From ihse at openjdk.org  Wed May 15 13:35:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 May 2024 13:35:05 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>

On Thu, 9 May 2024 07:50:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> WIP
>> 
>> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Hi Julian, sorry for not getting back to you.

The problem from my PoV is that this is a very large and intrusive patch in the build of the actual product, for a claimed problem in the tangential hsdis library. I have not understood a pressing business need to get a Windows/gcc port for hsdis, which means I can't really prioritize trying to understand this patch.

As you know, the build system does not currently really separate between "the OS is Windows" and "the toolchain is Microsoft". I understand that you want to fix that, and in theory I support it. However, you must also realize that making a complete fix of this requires a lot of work, for something that there is no clearly defined need. (After all, cl.exe works fine to create the build, has no apparent issues, and is as far as an "official" compiler for Windows as you can get.) That makes it fall squarely in the WIBNIs bucked ("wouldn't it be nice if...").

If you can fix just the hsdis build without changing anything outside the hsdis Makefiles, that would be a different story. Such a change would be limited in scope, easy to say it will not affect the product proper, and be easier to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2112546029

From lmesnik at openjdk.org  Wed May 15 15:00:19 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 May 2024 15:00:19 GMT
Subject: Integrated: 8332112: Update nsk.share.Log to don't print summary
 during VM shutdown hook
In-Reply-To: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com>
Message-ID: <5Dt76GGgzyQjfZ99ANQ4ee6zYAwQbF8NwU3uBRScILo=.5a66a525-9c21-49be-912f-5b83d262ede1@github.com>

On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.Log doing some cleanup and reporting errors in the cleanup method. This method is supposed to be executed by finalizer originally. However, now it is called only during shutdown hook. 
> The cleanup using Cleaner doesn't work. See https://bugs.openjdk.org/browse/JDK-8330760
> 
> The cleanup() method flush stream and print summary which should be already printed by complain method.
> 
> This cleanup is not necessary and printing summary usually is just disabled. It is enabled if the test called 'complain' method. However, the error should have been printed already in this method.
> 
> So it would be simple to remove this cleanup and reduce usage of Finalizable in vmTestbase tests.
> 
> Note: The 'verboseOnErrorEnabled' is just not used.
> 
> See isVerboseOnErrorEnabled.
> 
>     public boolean isVerboseOnErrorEnabled() {
>         return errorsSummaryEnabled;
>     }
> 
> 
> Tested with by running tests with different combinations (tier4-7) and tier1.

This pull request has now been integrated.

Changeset: 61aff6db
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61aff6db15d5bdda77427af5ce34d0fe43373197
Stats:     168 lines in 30 files changed: 2 ins; 134 del; 32 mod

8332112: Update nsk.share.Log to don't print summary during VM shutdown hook

Reviewed-by: dholmes, cjplummer

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

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

From alanb at openjdk.org  Wed May 15 15:59:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 15:59:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v5]
In-Reply-To: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
Message-ID: <suc3iBvDYlNQN67NthCn7mNhES7uotnhpwD94oLIWys=.13442394-d2c1-4118-893b-db62656c6708@github.com>

On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine warning text for JNI method binding

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 871:

> 869:             return IllegalNativeAccess.WARN;
> 870:         } else {
> 871:             fail("Value specified to --illegal-access not recognized:"

Typo in the message, should be --illegal-native-access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601898238

From mcimadamore at openjdk.org  Wed May 15 16:08:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 16:08:17 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/daf729f4..1c45e5d5

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

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

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

From kevinw at openjdk.org  Wed May 15 17:21:10 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 17:21:10 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
Message-ID: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>

Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.

In javax/management/remote/rmi/RMIConnectionImpl.java:
addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).

Manually testing JConsole, the MBean tab is fully populated and usable.

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

Commit messages:
 - Remove unnecessary Subject array in RMIConnectionImpl, update docs in RMIConnection
 - JConsole's MBean tab is blank after JMX Subject Delegation removal.

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

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

From dfuchs at openjdk.org  Wed May 15 17:52:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 15 May 2024 17:52:06 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:

> 982:         }
> 983:         if (names.length != filters.length) {
> 984:             final String msg = "The lengths of names and filters parameters are not same.";

I wonder if we should check that if present, `delegationSubjects.length == names.length`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602032906

From cjplummer at openjdk.org  Wed May 15 19:12:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:12:01 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

I'm just trying to understand current and previous behavior of jconsole a bit better. It sounds like jconsole always passes a non-null `delegationSubjects`, which results in an UOE, and you've changed to code to accept it as long as the entries are all null,  resulting in no UOE and jconsole properly displaying the mbean tab. But what I don't understand is why we are seeing this issue with jconsole when it appears it is already passes null for the `delegationSubjects` argument, even back as far as JDK 8u.

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113277694

From cjplummer at openjdk.org  Wed May 15 19:19:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:19:00 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests are not compatible with jtreg
 test factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <dswKYHoriYPPbkq_aBHMY2GXRnlkJG7FY_SEeqH0-tk=.92e7746e-9ff4-4386-a8ba-8c34a137aaaa@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

Changes look good. I think the CR needs a better title. Something that mentions "Virtual". Also, it's not the "test factory" we area talking about here. It is the "test thread factory".

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19244#pullrequestreview-2058820760

From amenkov at openjdk.org  Wed May 15 19:32:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 15 May 2024 19:32:09 GMT
Subject: Integrated: 8330066: HeapDumpPath and HeapDumpGzipLevel VM options do
 not mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC
In-Reply-To: <k5evL-GFFoLLSxW68S9JzmzmRbuT8FltD2En_SLOCv8=.e869b6ec-9e24-497c-90e8-e421f65c22ba@github.com>
References: <k5evL-GFFoLLSxW68S9JzmzmRbuT8FltD2En_SLOCv8=.e869b6ec-9e24-497c-90e8-e421f65c22ba@github.com>
Message-ID: <gwQk1_I-nt71ylVDhb8NbnDI4-KGkYihrufn7ZaJxJg=.3bd7e96d-28a4-4970-99f1-6ad4d9617ec9@github.com>

On Tue, 14 May 2024 00:44:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM options

This pull request has now been integrated.

Changeset: 43b109b1
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43b109b111e77d0f7b302debc0d76e4ac7c9ac56
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC

Reviewed-by: cjplummer, dholmes, yyang

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

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

From cjplummer at openjdk.org  Wed May 15 19:39:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:39:03 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <pMASnhPKhly_qC7Li9xIqAUAAihJrUgCQLwy0uYQaSA=.03ba9dcf-0b83-4b97-9653-bb4304909451@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
 <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com>
 <ER_eGP9KBvCs0cMbV-bFwcBm6NbuJOsMgp2o1wJKEOo=.581822fc-4ac5-42b8-8baf-9355c1735c71@github.com>
 <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com>
 <Y5OSw7X44QZuVeYFKMyD5TnDguvPv3uKM9X5-lO7_Is=.af3028fa-6606-4d8b-a8f4-0ec5050f8e79@github.com>
 <TA_0MV0DCHOLAFq2qDgqnPP5TvM-iFhg-kOOEXhgVBo=.d1945995-7e66-44b6-941b-b02a156df800@github.com>
 <EhEXq-iCKcsm83qhYqVP5r4XiVtUy7_5kGEKyc6Q61E=.ead998c3-bcd6-4b28-9d52-bb6941854d0b@github.com>
 <pMASnhPKhly_qC7Li9xIqAUAAihJrUgCQLwy0uYQaSA=.03ba9dcf-0b83-4b97-9653-bb4304909451@github.com>
Message-ID: <Ov3Xy9DwWdr1dgU4cYBhELCoh03oTkQn3zPOqFKdWaA=.c775e38c-50a8-4eb2-aa79-371e32db519f@github.com>

On Tue, 14 May 2024 23:19:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Okay, please, let me explain this one more time.
>> The original comments before method `check()` calls describe the testing scenario  (or configuration setup before the verifying check) but not the numbers expected to be returned by the JVMTI `GetObjectMonitorUsage`. For instance, if the testing scenario says: "count of threads waiting to enter: NUMBER_OF_ENTERING_THREADS" then it means there is a real number of these threads waiting to enter the monitor. And it does not matter if they are platform or virtual threads. They are really waiting to enter the monitor. However, the JVMTI `GetObjectMonitorUsage` won't include virtual threads into the returned results.
>> 
>> Now, I'm suggesting to add the following header for comments before each `check()` method call:
>> 
>> +            // The numbers below describe the testing scenario, not the expected results.
>> +            // The expected numbers are different for virtual threads because
>> +            // they are not supported by JVMTI GetObjectMonitorUsage.
>> 
>> Would it work for you (I've pushed an update)?
>
>> BTW, the "re-enter" comment should continue to be "i + 1".
>> I'm not sure why it was changed to "expEntryCount()".
> 
> It depends on what are we trying to describe. We either describe the testing scenario (the number of threads doing something) or the expected results. I understood that you wanted to describe the results instead of the scenario. And then it becomes problematic to do so as you can see.

Ok, I understand what you are saying now. I think your clarifying comment above helps a lot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602155030

From cjplummer at openjdk.org  Wed May 15 19:47:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:47:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <odXhY-u0RLRTriesku-Q37rBgA_7DyrwBGnuKL-N4hI=.0dccf599-a54a-432e-ab86-75757c7767cd@github.com>
Message-ID: <r6Ve1sTod38Favt4Za1XytXCqKGO2X3I8Wn3N6ybAuo=.b9ea363a-183e-49d2-a472-a01f1eeed08a@github.com>

On Wed, 1 May 2024 20:49:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test comments.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 369:
> 
>> 367: 
>> 368:     /**
>> 369:      * Returns an {@link ThreadReference} for the platform thread, if any,
> 
> Pre-existing issue: It should be "a" not "an", but then in the `@return` section we are using "the", so maybe we should use similar wording here: `...the {@link ThreadReference} of the platform thread...`

The above comment has not been addressed yet. Should be "a ThreadReference" or "the ThreadReference"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602163046

From cjplummer at openjdk.org  Wed May 15 19:55:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:55:02 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>
Message-ID: <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>

On Tue, 14 May 2024 23:56:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test comments.

Changes requested by cjplummer (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1535:

> 1533:       bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
> 1534:       if (is_virtual) {
> 1535:         skipped++;

Do we really need to maintain `skipped`. Isn't not adding to `nWait` the same as skipping?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1583:

> 1581:         assert(w != nullptr, "sanity check");
> 1582:         if (java_lang_VirtualThread::is_instance(thread_oop)) {
> 1583:           skipped++;

I don't think maintaining `skipped` does anything here.

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

PR Review: https://git.openjdk.org/jdk/pull/19030#pullrequestreview-2058882144
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602170079
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602171199

From kevinw at openjdk.org  Wed May 15 20:05:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 20:05:01 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
Message-ID: <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>

On Wed, 15 May 2024 17:49:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:
> 
>> 982:         }
>> 983:         if (names.length != filters.length) {
>> 984:             final String msg = "The lengths of names and filters parameters are not same.";
> 
> I wonder if we should check that if present, `delegationSubjects.length == names.length`?

That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602181014

From sspitsyn at openjdk.org  Wed May 15 20:06:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:06:27 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v5]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <EsaDgTI5-y5lRQIttq-mZEqFctn4pRok3rJ1ukfUwrQ=.753f9bd7-38f3-4160-9231-ded903a5205e@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: fixed minor typos in JDI and JDWP specs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/8438cf4a..95ea3621

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

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

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

From sspitsyn at openjdk.org  Wed May 15 20:12:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:12:03 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>
 <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>
Message-ID: <kQtojjN2jQbkyE7bvngIzoHqZkfivkamP3RpFJziiJM=.fe06f502-431b-4972-820a-f0b50182fa5c@github.com>

On Wed, 15 May 2024 19:51:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test comments.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1535:
> 
>> 1533:       bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>> 1534:       if (is_virtual) {
>> 1535:         skipped++;
> 
> Do we really need to maintain `skipped`. Isn't not adding to `nWait` the same as skipping?

Good suggestion, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602188546

From sspitsyn at openjdk.org  Wed May 15 20:18:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:18:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>
 <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>
Message-ID: <liwrAkVLAEFFNAhAXtpqzBGe6GV26nF2XGi3sXU9JKM=.4d21c274-deec-4f35-9765-7b1abed11ba2@github.com>

On Wed, 15 May 2024 19:52:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test comments.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1583:
> 
>> 1581:         assert(w != nullptr, "sanity check");
>> 1582:         if (java_lang_VirtualThread::is_instance(thread_oop)) {
>> 1583:           skipped++;
> 
> I don't think maintaining `skipped` does anything here.

Thank you for the question. It is needed at the line 1586 below to discount the index:

        if (java_lang_VirtualThread::is_instance(thread_oop)) {
          skipped++;
        } else {
          // If the thread was found on the ObjectWaiter list, then
          // it has not been notified.
          Handle th(current_thread, get_vthread_or_thread_oop(w));
1586:     ret.notify_waiters[i - skipped] = (jthread)jni_reference(calling_thread, th);
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602193077

From sspitsyn at openjdk.org  Wed May 15 20:21:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:21:14 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v6]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <-eAMFeNP4w4hzZm4HHW7RawOJtwcrwjdg09FfVJOqx8=.5c2bea51-eeb3-44f4-94fe-90e3eb01bc00@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: simplified a fragment by removing tmp local variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/95ea3621..f083fd65

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

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

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

From kevinw at openjdk.org  Wed May 15 20:29:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 20:29:05 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>
Message-ID: <x9i4QY2T69IETnVXf7HQGppcNpqg1p_WzL9EtCpR-bg=.e4a9c2b4-7371-4805-a726-34b561b3930f@github.com>

On Wed, 15 May 2024 19:09:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm just trying to understand current and previous behavior of jconsole a bit better.....

Right, to be clear it's not JConsole's fault.   The early part of JConsole's stack is:


...connection....
	at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl_Stub.addNotificationListeners(RMIConnectionImpl_Stub.java:136)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector.addListenersWithSubjects(RMIConnector.java:595)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector.addListenerWithSubject(RMIConnector.java:571)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.addNotificationListener(RMIConnector.java:1238)
	at jdk.jconsole/sun.tools.jconsole.MBeansTab$1.doInBackground(MBeansTab.java:93)
...older frames...


...and when it is running with an older JDK, RMIConnector.addListenerWithSubject() would create a new array of Subjects, containing what it was given (which is null).
It passes on the array, and then is going to get the UnsupportedOperationException.
i.e. Older client code passing a null Subject, actually "promotes" it to an array and hits the Exception, although it really is not trying to use the removed feature.

This problem is specifically with addListenerWithSubject.

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113397029

From sspitsyn at openjdk.org  Wed May 15 20:29:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:29:17 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v7]
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

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

  review: UNDO: removed incorrect simplification that removed a tmp local skipped

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19030/files
  - new: https://git.openjdk.org/jdk/pull/19030/files/f083fd65..7091a3f6

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

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

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

From lmesnik at openjdk.org  Wed May 15 20:33:03 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 May 2024 20:33:03 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests are not compatible with jtreg
 test factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <C5jXVDTsQjNbWkq1e32CoHGEConiWTQpDXT1nLzDtYA=.e80f7f69-8a48-438d-9be4-2bd9584842a2@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19244#pullrequestreview-2058946607

From sspitsyn at openjdk.org  Wed May 15 20:37:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 20:37:03 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v4]
In-Reply-To: <kQtojjN2jQbkyE7bvngIzoHqZkfivkamP3RpFJziiJM=.fe06f502-431b-4972-820a-f0b50182fa5c@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <YYmlRqqg8aUd9se3kRQP4hA_oNRhm7eTdKXg7mNttys=.a795ae42-e652-4d0b-a640-893437c0fa4d@github.com>
 <aGO7gYHNPSqClGLacerxUTix3J9Fp10JnKSmB1SGx04=.1c9f62e7-05bf-48ae-b880-daadbb736db9@github.com>
 <kQtojjN2jQbkyE7bvngIzoHqZkfivkamP3RpFJziiJM=.fe06f502-431b-4972-820a-f0b50182fa5c@github.com>
Message-ID: <0YzEv8zaHhoN7u7Iq8xN63266pMnnpGAeC-UkAbWLtg=.eb8764d0-fe4e-4bb2-895b-aaf3c97f5f85@github.com>

On Wed, 15 May 2024 20:09:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1535:
>> 
>>> 1533:       bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>>> 1534:       if (is_virtual) {
>>> 1535:         skipped++;
>> 
>> Do we really need to maintain `skipped`. Isn't not adding to `nWait` the same as skipping?
>
> Good suggestion, thanks. Fixed now.

I've undone this suggested simplification as it has not worked out. Please, see my answer on your next comment.

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1583:
>> 
>>> 1581:         assert(w != nullptr, "sanity check");
>>> 1582:         if (java_lang_VirtualThread::is_instance(thread_oop)) {
>>> 1583:           skipped++;
>> 
>> I don't think maintaining `skipped` does anything here.
>
> Thank you for the question. It is needed at the line 1586 below to discount the index:
> 
>         if (java_lang_VirtualThread::is_instance(thread_oop)) {
>           skipped++;
>         } else {
>           // If the thread was found on the ObjectWaiter list, then
>           // it has not been notified.
>           Handle th(current_thread, get_vthread_or_thread_oop(w));
> 1586:     ret.notify_waiters[i - skipped] = (jthread)jni_reference(calling_thread, th);
>         }

BTW: The simplification (getting rid of local `skipped`) you requested in previous comment damaged this fragment by making it incorrect. Here we need the `nWait` to account for virtual threads as well. Otherwise, the loop is shorted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602212314
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1602210128

From cjplummer at openjdk.org  Wed May 15 21:15:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 21:15:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v7]
In-Reply-To: <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
Message-ID: <UnFaYMkJZ1g01dq6cWelJmWMNB3ZNOBfuYQuhajTN-c=.9671cfb5-4cfe-416f-8385-3c4c7b8e1fb0@github.com>

On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: UNDO: removed incorrect simplification that removed a tmp local skipped

Changes look good now.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19030#pullrequestreview-2059028269

From cjplummer at openjdk.org  Wed May 15 21:23:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 21:23:05 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Ok. So the older version of jconsole does pass the empty delegationSubjects, not null. Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113474704

From cjplummer at openjdk.org  Wed May 15 21:28:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 21:28:00 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <w0j3woxUuN5cdlZMzHyGIwv5OgCb4jSFlziVUMnnGt8=.094de6b2-b135-4525-a216-27fd4f85eb95@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

LGTM

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19254#pullrequestreview-2059047063

From apangin at openjdk.org  Wed May 15 21:28:01 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 15 May 2024 21:28:01 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <ekFxAkZToUZtPLTgPFbcrq6uPusfTKQKBk2bP_DGL04=.326e61fd-1897-4644-adaa-7993d09fb00f@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

@coleenp Could you please review the PR since it reverts one line from one of your previous commits. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19254#issuecomment-2113479138

From kevinw at openjdk.org  Wed May 15 21:41:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 21:41:04 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
Message-ID: <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>

On Wed, 15 May 2024 21:20:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?

I don't think there is, JConsole has a hard null in this call.  Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.

If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone.
Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113498480

From sspitsyn at openjdk.org  Wed May 15 22:03:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 22:03:04 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v7]
In-Reply-To: <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
Message-ID: <bx_77Xa8Ou_jriGZQlfe4NPrEcWHdOYXkROO6uD1tA8=.bce22edc-996f-43ea-bea2-632a17edc703@github.com>

On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: UNDO: removed incorrect simplification that removed a tmp local skipped

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/19030#issuecomment-2113523235

From sspitsyn at openjdk.org  Wed May 15 22:48:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 22:48:01 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Looks good in general. Posted a couple of questions though.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 979:

> 977:             for (Subject s: delegationSubjects) {
> 978:                 if (s != null) {
> 979:                     throw new UnsupportedOperationException("Subject Delegation has been removed.");

Q1: Would it make sense to provide any details about the failing `delegationSubject` element?
Q2: Does this fix needs a CSR?

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

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2059157190
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602337036

From sspitsyn at openjdk.org  Wed May 15 22:59:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 22:59:02 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <5b211vTNYsdE-dj-PdfDkrw1UGAit9OVXUnxQ0nudCs=.d8382b7b-31ac-4388-8eba-eaf2558f7969@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

Looks good and low risk.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19254#pullrequestreview-2059177894

From cjplummer at openjdk.org  Wed May 15 23:43:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 23:43:01 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
Message-ID: <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>

On Wed, 15 May 2024 21:38:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
> 
> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
> 
> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.

If jconsole is passing null, why is it triggering this exception?

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113656022

From jpai at openjdk.org  Thu May 16 01:19:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 01:19:09 GMT
Subject: RFR: 8307778: com/sun/jdi/cds tests fail with jtreg's Virtual test
 thread factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <RrfFQG_DORxpC8d6cyEl4Ez5ODMxyODX0eoZUOzUGiY=.bb841723-e122-4452-9fb5-0b89d068f741@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

Thank you all for the reviews. 

> I think the CR needs a better title. Something that mentions "Virtual". Also, it's not the "test factory" we are talking about here. It is the "test thread factory".

I have now updated the title of the JBS issue (and this PR) to "com/sun/jdi/cds tests fail with jtreg's Virtual test thread factory". No other changes have been done. I'll integrate this in a few hours from now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19244#issuecomment-2113729065

From sspitsyn at openjdk.org  Thu May 16 02:41:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 May 2024 02:41:17 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers
Message-ID: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>

The following RFE was fixed recently:
[8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code

It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
This update is to make it clear that `nullptr` is C programming language `null` pointer.

I think we do not need a CSR for this fix.

Testing: N/A (not needed)

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

Commit messages:
 - 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers

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

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

From jpai at openjdk.org  Thu May 16 05:45:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 05:45:06 GMT
Subject: Integrated: 8307778: com/sun/jdi/cds tests fail with jtreg's Virtual
 test thread factory
In-Reply-To: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
References: <bzBh7SIrIhrpkLoXymZgi3nsdT6TvYnJLlno6iOQMtI=.57096f4c-cf34-4c1b-a577-902464bb24f9@github.com>
Message-ID: <hS0wpCFJ_XFgX8kiYqNFKULbIqT7257jmU8hlnhz-JY=.1ae7ae48-6ce0-4bc4-97a0-3684328316f1@github.com>

On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg launches these tests through a virtual thread?
> 
> These tests aren't actually incompatible with virtual threads. The real issue is that in https://bugs.openjdk.org/browse/JDK-8305608, a test infrastructure class `test/jdk/com/sun/jdi/VMConnection.java` was changed to use the `test.class.path` system property instead of the previously used `test.classes`.
> 
> That change missed out updating the `test/jdk/com/sun/jdi/cds/` tests to pass along the classpath through the `test.class.path` system property. As a result these tests still use the old `test.classes` system property to pass around the test classpath and thus causes these tests to fail. The reason why this only impacts virtual threads is noted by Chris in this JBS comment https://bugs.openjdk.org/browse/JDK-8305608?focusedId=14572100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14572100.
> 
> The commit in this PR updates the `CDSJDITest` to pass along `test.class.path` instead of `test.classes`. The `CDSJDITest` is only used in the tests under `test/jdk/com/sun/jdi/cds/`, so nothing else should be impacted by this change.
> 
> I ran these changes against both launching with platform thread as well as virtual thread and these tests now pass in both these cases.

This pull request has now been integrated.

Changeset: fe8a2aff
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe8a2aff3129b515c2a0f3ab96f5e3ad6cef7b70
Stats:     5 lines in 2 files changed: 0 ins; 3 del; 2 mod

8307778: com/sun/jdi/cds tests fail with jtreg's Virtual test thread factory

Reviewed-by: dholmes, sspitsyn, cjplummer, lmesnik

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

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

From jwaters at openjdk.org  Thu May 16 07:59:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 May 2024 07:59:07 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
 <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>
Message-ID: <4QTrXORVLmXOdBxVAdYyAE9M7HTfxOjcW0NVtitY-og=.aef997d7-96d6-4992-b308-d951046c920f@github.com>

On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Hi Julian, sorry for not getting back to you.
> 
> The problem from my PoV is that this is a very large and intrusive patch in the build of the actual product, for a claimed problem in the tangential hsdis library. I have not understood a pressing business need to get a Windows/gcc port for hsdis, which means I can't really prioritize trying to understand this patch.
> 
> As you know, the build system does not currently really separate between "the OS is Windows" and "the toolchain is Microsoft". I understand that you want to fix that, and in theory I support it. However, you must also realize that making a complete fix of this requires a lot of work, for something that there is no clearly defined need. (After all, cl.exe works fine to create the build, has no apparent issues, and is as far as an "official" compiler for Windows as you can get.) That makes it fall squarely in the WIBNIs bucked ("wouldn't it be nice if...").
> 
> If you can fix just the hsdis build without changing anything outside the hsdis Makefiles, that would be a different story. Such a change would be limited in scope, easy to say it will not affect the product proper, and be easier to review.

Oh, no worries. Sorry for sounding a little impatient.

The problem is that there are areas in the build system that will need changing to support hsdis compilation, not just the hsdis Makefile and autoconf file itself. I can try to work on minimizing the amount of changes to non-hsdis files (I was hoping the current changes were small enough, but it seems they are not), but I believe it's impossible to achieve this by only touching the hsdis Makefile and lib-hsdis.m4. That is, there will necessarily be changes, no matter how minimal, to non-hsdis files.

As for why do this at all, I was mainly driven by seeing the hack in place for the binutils backend on Windows. It only supports Cygwin, of which the gcc installation is subpar compared to the newer gcc provided by some MSYS2 subsystems (MINGW64 gcc is primarily battle tested on MSYS2, on Cygwin it doesn't get as much attention and misses out further fixes and enhancements from the MSYS2 team, for instance it even links to the obsolete msvcrt library), and the hack itself has several flaws that don't seem apparent at first (For instance, -lpthread will link to libwinpthread.dll and result in an invisible dependency on that dll depending on the Windows platform, which will cause loading hsdis to silently fail depending on how it's loaded for seemingly random reasons!). I wanted to replace that (or I guess provide a better alternative) by adding semi proper support to the hsdis build for the more modern and better battle tested gcc that some MSYS2 subsystems provide, to streamline comp
 iling the binutils hsdis on Windows. So this is mainly about hsdis-binutils on Windows. hsdis-capstone I also decided to support because it's small and relatively easy to pile on top of the existing work, and MSYS2 also provides Capstone as well. The same unfortunately could not be said for hsdis-llvm, which was significantly more complex than Capstone is

I'm not sure where to go from here. I could support gcc for hsdis binutils by extending the hack that exists for Cygwin, but I _really_ don't want to do that. I could enhance the build system to semi properly support gcc for hsdis only, as I've done, but the changes will necessarily touch non hsdis files as well, no matter how minimal they are. I'll return this to draft for the time being I suppose, I'd be interested in hearing which way forward you prefer though

But while I work on making this change even smaller and easier to review, could I ask the above questions again? (Well, except for the FIXPATH one, you can ignore that)



> @magicus I think I might need some help here. Currently all the Cygwin stuff is gated behind ifeq ($(TOOLCHAIN_TYPE), microsoft) checks... should they be behind isBuildOsEnv cygwin checks instead? I don't know how to add support for Cygwin gcc for most of hsdis, since it is quite different from the more modern gcc distributions that are found in places like MSYS2 and MINGW64. But most of the existing logic seems to accomodate more for the Microsoft compiler than it is concerned about the OS environment being used, and for this reason I can't tell which of the 2 checks to use for the existing hack that switches from microsoft to gcc. Also, gcc doesn't require FIXPATH, but Microsoft does, but I don't want to check for microsoft inside TOOLCHAIN_FIND_COMPILER, what should I do instead to ensure gcc doesn't get FIXPATH while Microsoft does?



> Also @magicus, what is the typical path passed to --with-binutils like on Windows? Something like --with-binutils=/c/Users/vertig0/Downloads/binutils-2.42 doesn't work correctly, since the include path to dis-asm.h would then become `#include "/c/Users/vertig0/Downloads/binutils-2.42/include/dis-asm.h"` Which causes a configure check to fail on the compile stage since gcc cannot recognise the MINGW-esque /c/ as a drive, and then causes configure to erroneously report binutils as using the Old API when it's in fact using the New API. --with-binutils=C:/Users/vertig0/Downloads/binutils-2.42 on the other hand works as expected. Should there be a fixup for the path there so gcc can recognise it properly?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2114331612

From alanb at openjdk.org  Thu May 16 08:01:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 08:01:05 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers
In-Reply-To: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
Message-ID: <M7JQq1L8Ff9A8PJnKSwtJtROvC-TXhXs_6t5tEkCBiw=.de232f65-2354-44fc-bb90-aa9557b8bb13@github.com>

On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
> 
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
> This update is to make it clear that `nullptr` is C programming language `null` pointer.
> 
> I think we do not need a CSR for this fix.
> 
> Testing: N/A (not needed)

src/hotspot/share/prims/jvmti.xml line 1008:

> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
> 1007:     returned as <code>nullptr</code> which is C programming language
> 1008:     <code>null</code> pointer.

Shouldn't this be "NULL"?  In any case, I think it would be helpful to expand this a bit to make it clear that usages of "nullptr" in parameter and error descriptions should be read or treated as  "NULL" when developing an agent in C rather than C++.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1602803174

From kevinw at openjdk.org  Thu May 16 08:28:02 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 08:28:02 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
Message-ID: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>

On Wed, 15 May 2024 23:40:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If jconsole is passing null, why is it triggering this exception?

JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.

(JConsole running on jdk-23 can connect to jdk-23 fine.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2114453521

From kevinw at openjdk.org  Thu May 16 09:05:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 09:05:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>
Message-ID: <8VfBzZdiXsFsNs9s-TbP9pFAxUTBpjGVyicTU-oesK8=.63a74189-cce2-4baa-bfb6-7eb79909c017@github.com>

On Wed, 15 May 2024 22:44:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 979:
> 
>> 977:             for (Subject s: delegationSubjects) {
>> 978:                 if (s != null) {
>> 979:                     throw new UnsupportedOperationException("Subject Delegation has been removed.");
> 
> Q1: Would it make sense to provide any details about the non-null `delegationSubject` element?
> Q2: Does this fix needs a CSR? My guess is that this issue is very minor, so CSR is not needed.

Q1 We have a couple of places where we use that text, when a non-null Subject is given.  It's quite generic and that is a good fit.  Your app would have to go to a significant effort to use the Subject Delegation feature, and we aren't aware of any apps that use it.  If JConsole were using the feature, you would know as you would have had to specifically configure it somehow (as well as on the remote end with SM and policies), so I really think the generic message is explicit enough.

Q2 Yes, Daniel very quickly added the CSR flag.  I was presuming that "paperwork" would need doing, although yes as spec changes go, it is very very minor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602917924

From dfuchs at openjdk.org  Thu May 16 09:44:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 09:44:12 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
Message-ID: <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>

On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:
>> 
>>> 982:         }
>>> 983:         if (names.length != filters.length) {
>>> 984:             final String msg = "The lengths of names and filters parameters are not same.";
>> 
>> I wonder if we should check that if present, `delegationSubjects.length == names.length`?
>
> That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.

Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603000965

From kevinw at openjdk.org  Thu May 16 10:20:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 10:20:06 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
Message-ID: <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>

On Thu, 16 May 2024 09:40:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.
>
> Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.

That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.

(also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)

We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...

IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603064299

From dfuchs at openjdk.org  Thu May 16 10:32:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 10:32:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
Message-ID: <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>

On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.
>
> That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.
> 
> (also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)
> 
> We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...
> 
> IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)

This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603087272

From kevinw at openjdk.org  Thu May 16 10:40:02 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 10:40:02 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
Message-ID: <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>

On Thu, 16 May 2024 10:26:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.
>> 
>> (also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)
>> 
>> We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...
>> 
>> IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)
>
> This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
> I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.

Yes, completely understand.  I just don't think it has any benefit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603106058

From jsjolen at openjdk.org  Thu May 16 11:03:05 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 16 May 2024 11:03:05 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <m5Vs40Qd_vIKwXCDCDvFaa1reItjyWLtg7LeZ6vSFrQ=.7381703d-c86f-4de0-9e2c-308d36e56e90@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

Please wait 24 hours before attempting to integrate. In other words: Do not sponsor this until 24 hours has passed since opening the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19254#issuecomment-2114911425

From jpai at openjdk.org  Thu May 16 11:07:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:07:04 GMT
Subject: RFR: 8332098: Add missing @ since tags to jdk.jdi [v2]
In-Reply-To: <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
 <Oa5ThtKxUyO2AeAuw4bY49282oJ704VVt2HsFKCPaGs=.cbdd8565-bec8-41fb-a869-5d225e83f386@github.com>
Message-ID: <g3RVPIcU2mUR_IVqNhmnIKSt93wC2xWqyN_arw9eQbE=.73c66885-09f0-4ea4-ad91-d173b951b186@github.com>

On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Please review this simple change where I add "@ since" tags to the package-info file of the following packages
>> 
>> com.sun.jdi
>> com.sun.jdi.connect
>> com.sun.jdi.connect.spi
>> com.sun.jdi.event
>> com.sun.jdi.request
>> 
>> I used the unix grep command to find the oldest "@ since" in each package and used that value, as it's hard to get the source code of JDK 1-5
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit

No changes have been done to the PR since it was last approved by Chris few days back (that's a good thing). I'll go ahead and sponsor this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19200#issuecomment-2114924570

From duke at openjdk.org  Thu May 16 11:07:05 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 16 May 2024 11:07:05 GMT
Subject: Integrated: 8332098: Add missing @ since tags to jdk.jdi
In-Reply-To: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com>
Message-ID: <MYqTc5Ua-TUUUw80lYE28WNvmXSmMnR6EKktS77-8Qo=.f59ecd6f-3eec-4af1-ab2d-aba8aebd6065@github.com>

On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple change where I add "@ since" tags to the package-info file of the following packages
> 
> com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
> 
> I used the unix grep command to find the oldest "@ since" in each package and used that value, as it's hard to get the source code of JDK 1-5
> TIA

This pull request has now been integrated.

Changeset: a33cb904
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a33cb9045b2c0cae7d894715d1484e77b7607de6
Stats:     15 lines in 5 files changed: 10 ins; 0 del; 5 mod

8332098: Add missing @ since tags to jdk.jdi

Reviewed-by: alanb, cjplummer

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

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

From jpai at openjdk.org  Thu May 16 11:24:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:24:10 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <RUCP0y-ucqEWVGtNsxZ_c5l2t0sddT8sl247K_JYUls=.35b6b052-336b-462e-a19f-84150c738763@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:

> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
> 72: \                  This option will be removed in a future release.\n\

Should this specify the current default value for this option if it isn't set?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603157916

From dfuchs at openjdk.org  Thu May 16 11:41:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 11:41:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
 <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
Message-ID: <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>

On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
>> I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.
>
> Yes, completely understand.  I just don't think it has any benefit.

Hmmm... the spec still says:

     * @throws IllegalArgumentException if <code>names</code> or
     * <code>filters</code> is null, or if <code>names</code> contains
     * a null element, or if the three arrays do not all have the same
     * size.
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603184648

From jpai at openjdk.org  Thu May 16 11:45:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:45:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:


java --enable-native-access=M1,M2 -jar foo.jar

where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2115005638

From kevinw at openjdk.org  Thu May 16 11:46:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 11:46:30 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v2]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  IllegalArgumentException throws doc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/ef84485e..6c97b5ed

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

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

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

From kevinw at openjdk.org  Thu May 16 11:46:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 11:46:30 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v2]
In-Reply-To: <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
 <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
 <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>
Message-ID: <PbXY6y7WNwrx3NStoFzbQwJ04Fw6DqhjvtzjS_b2nQ4=.ef440a2c-138b-4332-89cc-a3729f1f0511@github.com>

On Thu, 16 May 2024 11:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yes, completely understand.  I just don't think it has any benefit.
>
> Hmmm... the spec still says:
> 
>      * @throws IllegalArgumentException if <code>names</code> or
>      * <code>filters</code> is null, or if <code>names</code> contains
>      * a null element, or if the three arrays do not all have the same
>      * size.
>  ```

Thanks for additionally spotting the throws IAE needs updating, adding that now... (Will update the CSR also.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603191504

From mcimadamore at openjdk.org  Thu May 16 11:50:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:50:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
Message-ID: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>

On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:
> 
> ```
> java --enable-native-access=M1,M2 -jar foo.jar
> ```
> 
> where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

The options are additive - e.g. the enable-native-access in the manifest will add up to the enable-native-access in the command line, so effectively it will be as if you were running with --enable-native-access=M1,M2,ALL-UNNAMED

> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
> 
>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>> 72: \                  This option will be removed in a future release.\n\
> 
> Should this specify the current default value for this option if it isn't set?

We already do, see
https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2115012361
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603195671

From jpai at openjdk.org  Thu May 16 11:58:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:58:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
Message-ID: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>

On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
>> 
>>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>>> 72: \                  This option will be removed in a future release.\n\
>> 
>> Should this specify the current default value for this option if it isn't set?
>
> We already do, see
> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.

I don't have a strong opinion on this, I think either one is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603205279

From mcimadamore at openjdk.org  Thu May 16 12:20:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:20:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
 <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
Message-ID: <qpY76_mtbXFOYTvN5L7CXAZ7ZrsaLRFCjhoRB9WzzEk=.f53b98b1-6ad5-4499-98a0-aa8080b49cf0@github.com>

On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> We already do, see
>> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582
>
> This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.
> 
> I don't have a strong opinion on this, I think either one is fine.

Ah, apologies, I was looking in the wrong place. I agree that we should specify default in the launcher, as well as in the man pages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603233038

From mcimadamore at openjdk.org  Thu May 16 12:23:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:23:44 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add note on --illegal-native-access default value in the launcher help

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/1c45e5d5..3a0db276

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

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

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

From coleenp at openjdk.org  Thu May 16 13:58:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 May 2024 13:58:04 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <9MCc5CH-ddXg3f6pPVB59p4FF49OvZc8l4sktT4mqLY=.e30a0f9c-d014-4325-b77b-299cb7384c99@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

This is fine to revert.  I didn't see this field in SA so eagerly removed it.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19254#pullrequestreview-2060857374

From cjplummer at openjdk.org  Thu May 16 15:31:15 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 May 2024 15:31:15 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Simplify by getting rid of special logic around leaf monitors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/1c6a2e34..c3bd1716

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

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

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

From shade at openjdk.org  Thu May 16 16:36:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 16 May 2024 16:36:02 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <TyHApqgtPkXGKWTgF2FoNsLgm0TioD9lXvJY4ZFjQQc=.c4a6fc39-3fff-4161-8ec1-1cd712e73d57@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19254#pullrequestreview-2061331053

From shade at openjdk.org  Thu May 16 16:36:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 16 May 2024 16:36:03 GMT
Subject: RFR: 8332327: Return _methods_jmethod_ids field back in VMStructs
In-Reply-To: <m5Vs40Qd_vIKwXCDCDvFaa1reItjyWLtg7LeZ6vSFrQ=.7381703d-c86f-4de0-9e2c-308d36e56e90@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
 <m5Vs40Qd_vIKwXCDCDvFaa1reItjyWLtg7LeZ6vSFrQ=.7381703d-c86f-4de0-9e2c-308d36e56e90@github.com>
Message-ID: <--X2yEIBcHf36UAqIcn04d9QNyzHdXmP9oz8hlyfWHQ=.17c793e1-2b6a-4580-a34f-3a0863f96c53@github.com>

On Thu, 16 May 2024 11:00:33 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Please wait 24 hours before attempting to integrate. In other words: Do not sponsor this until 24 hours has passed since opening the PR.

OTOH, I would say this is good and _trivial_, so the usual 24 hour rule does not really apply. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19254#issuecomment-2115695457

From kevinw at openjdk.org  Thu May 16 16:58:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 16:58:04 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
Message-ID: <mHHrhgttDb-F6fJlVSXo8KXnv9OIs9vCeu4rp6SWKDM=.d2c06d3d-26ee-4f5f-a580-98a762a712d1@github.com>

On Thu, 16 May 2024 15:31:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify by getting rid of special logic around leaf monitors.

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

> 1747:  * the JDWP Command Reader thread and the PopFrame() target thread will grab
> 1748:  * both of these locks. However, one curious trait of these two locks is that
> 1749:  * the these two threads do not both grab them in the same order (and they need

nit: "that the these two"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1603728625

From kevinw at openjdk.org  Thu May 16 17:40:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 17:40:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
Message-ID: <Hbd9xr14HDxTyrhkGXttxAwfME9Ntl1wCyoelpgS314=.be9ef44a-4278-450c-a8fa-50081cd1c5c1@github.com>

On Thu, 16 May 2024 15:31:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify by getting rid of special logic around leaf monitors.

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

> 1779:  * popFrameEventLock. Meanwhile when the target thread gets the SINGLE_STEP event,
> 1780:  * it always enters popFrameProceedLock first (which is always available), then
> 1781:  * popFrameProceedLock second. It will always succeed because the Reader thread

Is that "then popFrameEventLock second"

Drawing these out in two columns I can't see a deadlock either 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1603777908

From alanb at openjdk.org  Thu May 16 18:43:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 18:43:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/System.java line 2023:

> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
> 2022:      * @throws     IllegalCallerException If the caller is in a module that
> 2023:      *             does not have native access enabled.

The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

src/java.base/share/man/java.1 line 587:

> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.

"This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 

This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920

From cjplummer at openjdk.org  Thu May 16 19:29:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 May 2024 19:29:05 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers
In-Reply-To: <M7JQq1L8Ff9A8PJnKSwtJtROvC-TXhXs_6t5tEkCBiw=.de232f65-2354-44fc-bb90-aa9557b8bb13@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <M7JQq1L8Ff9A8PJnKSwtJtROvC-TXhXs_6t5tEkCBiw=.de232f65-2354-44fc-bb90-aa9557b8bb13@github.com>
Message-ID: <PwjaSpsllCo3E4AfH0zIzQL-RLUoY17ZBBKi9SftLY0=.a501219e-a8fc-42bb-aae3-9d7e410f332f@github.com>

On Thu, 16 May 2024 07:57:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
>> 
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
>> This update is to make it clear that `nullptr` is C programming language `null` pointer.
>> 
>> I think we do not need a CSR for this fix.
>> 
>> Testing: N/A (not needed)
>
> src/hotspot/share/prims/jvmti.xml line 1008:
> 
>> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
>> 1007:     returned as <code>nullptr</code> which is C programming language
>> 1008:     <code>null</code> pointer.
> 
> Shouldn't this be "NULL"?  In any case, I think it would be helpful to expand this a bit to make it clear that usages of "nullptr" in parameter and error descriptions should be read or treated as  "NULL" when developing an agent in C rather than C++.

Yes, I think it should by NULL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1603929609

From dcubed at openjdk.org  Thu May 16 19:56:08 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 May 2024 19:56:08 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <vZMxz_pv7Q6MV3YGDoBfTeUQQvFzMrXEFLHZzgtpjbQ=.e4429b55-c4e7-4314-acb0-da7d34c4d356@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
 <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
 <OySW23RnwQQOK1Dl721B1uHiculZ6Qx-l0sNm5gRl7E=.7ffd070e-1f0d-4f2a-bbf3-5f7dcbe520b0@github.com>
 <uW1YBI63VbidNq3eAkOQFUfxOsHFW_ZOTkyWW4IYCrE=.1dda1260-31b0-480a-9d53-cff2b7506ad0@github.com>
 <vZMxz_pv7Q6MV3YGDoBfTeUQQvFzMrXEFLHZzgtpjbQ=.e4429b55-c4e7-4314-acb0-da7d34c4d356@github.com>
Message-ID: <1riS2rxi8S3odLFxNcMLJloR00dRiKKpEQnd7uIGxEw=.590cba72-b756-4bab-9522-59ff0613140b@github.com>

On Wed, 15 May 2024 06:00:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I'm not sure this answered Chris' query properly. Or I'm reading Chris' query wrong.
>> 
>> Perhaps this is not what Chris had in mind, but I'm wondering what happens in some
>> Thread-A when it is checked and passed by but then Thread-A sets the flag in itself
>> after the for-loop has passed it by. Does that Thread-A flag value get lost?
>
>> Perhaps this is not what Chris had in mind, but I'm wondering what happens in some
>> Thread-A when it is checked and passed by but then Thread-A sets the flag in itself
>> after the for-loop has passed it by. Does that Thread-A flag value get lost?
> 
> Thank you for the question.
> The Thread-A sets the flag optimistically and then re-checks if `sync_protocol_enabled()` and any disabler exists. It can be global disbaler (`_VTMS_transition_disable_for_all_count > 0`) or disabler of `Thread-A` only (`java_lang_Thread::VTMS_transition_disable_count(vth()) > 0`). If any disabler exists then `Thread-A` clears the optimistic settings and goes with the pessimistic approach under protection of `JvmtiVTMSTransition_lock`.
> 
> Please, let me know if you still have questions.

This algorithm sounds correct. Thanks for closing the loop on my belated comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1603957324

From mullan at openjdk.org  Thu May 16 20:07:04 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 May 2024 20:07:04 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v2]
In-Reply-To: <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
Message-ID: <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>

On Thu, 16 May 2024 11:46:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IllegalArgumentException throws doc update

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 959:

> 957:      * <code>NotificationFilters</code>.  Elements of this array can
> 958:      * be null.
> 959:      * @param delegationSubjects should be {@code null}, but a non-null

Would it be more clear to say: "should be {@code null}. However, an array where every entry is null is also accepted for compatibility reasons."

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 960:

> 958:      * be null.
> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 960:      * array is accepted for compatibilty reasons, which must not contain

Typo: s/compatibilty/compatibility/

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 969:

> 967:      * @throws IllegalArgumentException if <code>names</code> or
> 968:      * <code>filters</code> is null, or if <code>names</code> contains
> 969:      * a null element, or if these two arrays do not have the same size.

Was this actually an oversight in the previous change to remove subject delegation? When `delegationSubjects` is null, then the 3 arrays are never going to be the same size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603957397
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603965135
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603963533

From kevinw at openjdk.org  Thu May 16 20:17:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 20:17:18 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

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

 - add an 'also'
 - typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/6c97b5ed..68c791e7

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

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

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

From kevinw at openjdk.org  Thu May 16 20:17:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 20:17:18 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v2]
In-Reply-To: <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
 <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>
Message-ID: <rd5PPDVzoXGoU4ApmUQBP7S5xJppjkuRan6GeQbt-j4=.40adc121-ee90-47f4-b8de-6e85adec5338@github.com>

On Thu, 16 May 2024 19:53:48 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IllegalArgumentException throws doc update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 959:
> 
>> 957:      * <code>NotificationFilters</code>.  Elements of this array can
>> 958:      * be null.
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 
> Would it be more clear to say: "should be {@code null}. However, an array where every entry is null is also accepted for compatibility reasons."

Yes, I like adding the "also".

> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 960:
> 
>> 958:      * be null.
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>> 960:      * array is accepted for compatibilty reasons, which must not contain
> 
> Typo: s/compatibilty/compatibility/

oops yes thanks, done.

> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 969:
> 
>> 967:      * @throws IllegalArgumentException if <code>names</code> or
>> 968:      * <code>filters</code> is null, or if <code>names</code> contains
>> 969:      * a null element, or if these two arrays do not have the same size.
> 
> Was this actually an oversight in the previous change to remove subject delegation? When `delegationSubjects` is null, then the 3 arrays are never going to be the same size.

Yes, this is an oversight from the previous change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603976969
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603974595
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603975797

From kbarrett at openjdk.org  Thu May 16 23:38:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 16 May 2024 23:38:04 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers
In-Reply-To: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
Message-ID: <KD9R-pWTbNmk2X_DXiILVZWc-njmTKsT9eM3bXs8hL0=.31b72eff-aa4c-4585-bfeb-b666f27c9925@github.com>

On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
> 
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
> This update is to make it clear that `nullptr` is C programming language `null` pointer.
> 
> I think we do not need a CSR for this fix.
> 
> Testing: N/A (not needed)

Changes requested by kbarrett (Reviewer).

src/hotspot/share/prims/jvmti.xml line 1008:

> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
> 1007:     returned as <code>nullptr</code> which is C programming language
> 1008:     <code>null</code> pointer.

Perhaps instead something like

"returned as a null pointer (C <code>NULL</code> or C++ <code>nullptr</code>)."

"null pointer" is the generic phrase used in both the C and C++ standards.

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

PR Review: https://git.openjdk.org/jdk/pull/19257#pullrequestreview-2059896023
PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1602805633

From sspitsyn at openjdk.org  Fri May 17 00:43:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 May 2024 00:43:18 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
Message-ID: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>

> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
> 
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
> This update is to make it clear that `nullptr` is C programming language `null` pointer.
> 
> I think we do not need a CSR for this fix.
> 
> Testing: N/A (not needed)

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

  review: corrected the nullptr clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19257/files
  - new: https://git.openjdk.org/jdk/pull/19257/files/fd0e8d43..9fe639e1

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

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

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

From sspitsyn at openjdk.org  Fri May 17 00:43:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 May 2024 00:43:19 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <KD9R-pWTbNmk2X_DXiILVZWc-njmTKsT9eM3bXs8hL0=.31b72eff-aa4c-4585-bfeb-b666f27c9925@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <KD9R-pWTbNmk2X_DXiILVZWc-njmTKsT9eM3bXs8hL0=.31b72eff-aa4c-4585-bfeb-b666f27c9925@github.com>
Message-ID: <k0WQywNEN45zwk5entj15wq5g-tWrbr3Y733PTozoVY=.5ff79f1a-1ab3-43de-849d-943b120871e9@github.com>

On Thu, 16 May 2024 07:59:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: corrected the nullptr clarification
>
> src/hotspot/share/prims/jvmti.xml line 1008:
> 
>> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
>> 1007:     returned as <code>nullptr</code> which is C programming language
>> 1008:     <code>null</code> pointer.
> 
> Perhaps instead something like
> 
> "returned as a null pointer (C <code>NULL</code> or C++ <code>nullptr</code>)."
> 
> "null pointer" is the generic phrase used in both the C and C++ standards.

Thank you, Kim. I like this suggestion. Updated now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1604210615

From sspitsyn at openjdk.org  Fri May 17 00:43:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 May 2024 00:43:19 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <PwjaSpsllCo3E4AfH0zIzQL-RLUoY17ZBBKi9SftLY0=.a501219e-a8fc-42bb-aae3-9d7e410f332f@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <M7JQq1L8Ff9A8PJnKSwtJtROvC-TXhXs_6t5tEkCBiw=.de232f65-2354-44fc-bb90-aa9557b8bb13@github.com>
 <PwjaSpsllCo3E4AfH0zIzQL-RLUoY17ZBBKi9SftLY0=.a501219e-a8fc-42bb-aae3-9d7e410f332f@github.com>
Message-ID: <vZOQguMgH4zW8Av7vLMq4zwNNxDRYJq2mxzdKqNQ4_c=.6bb9dfc3-86d4-465c-b8e6-187c08238895@github.com>

On Thu, 16 May 2024 19:26:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 1008:
>> 
>>> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
>>> 1007:     returned as <code>nullptr</code> which is C programming language
>>> 1008:     <code>null</code> pointer.
>> 
>> Shouldn't this be "NULL"?  In any case, I think it would be helpful to expand this a bit to make it clear that usages of "nullptr" in parameter and error descriptions should be read or treated as  "NULL" when developing an agent in C rather than C++.
>
> Yes, I think it should by NULL.

Thank you for suggestions. I've changed it as Kim suggested below.
Please, let me know if it is not good enough, or some additions are needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1604211567

From lmesnik at openjdk.org  Fri May 17 01:53:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 May 2024 01:53:14 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name is not safe
Message-ID: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>

The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.

It happens when thread_name is set for tracing from jvmti functions.
See:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 

The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.

The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 

Verified by running jvmti/jdi/jdb tests with tracing enabled.

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

Commit messages:
 - include updated.
 - 8332259

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

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

From kbarrett at openjdk.org  Fri May 17 01:55:08 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 17 May 2024 01:55:08 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
Message-ID: <EPGUji1E0uZw40tdsjdv9ZYBhKzMOuzvfKcW0IlhjHo=.d49983b4-2840-4676-ac89-334808e87f70@github.com>

On Fri, 17 May 2024 00:43:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
>> 
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
>> This update is to make it clear that `nullptr` is C programming language `null` pointer.
>> 
>> I think we do not need a CSR for this fix.
>> 
>> Testing: N/A (not needed)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: corrected the nullptr clarification

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19257#pullrequestreview-2062184501

From dholmes at openjdk.org  Fri May 17 02:03:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 May 2024 02:03:02 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
Message-ID: <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>

On Fri, 17 May 2024 00:43:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
>> 
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
>> This update is to make it clear that `nullptr` is C programming language `null` pointer.
>> 
>> I think we do not need a CSR for this fix.
>> 
>> Testing: N/A (not needed)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: corrected the nullptr clarification

But this clarification doesn't actually clarify that the rest of the spec uses `nullptr`. Based on the proposed wording I would expect things like:

The function may return <code>nullptr</code>

to say

The function may return a null pointer

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19257#pullrequestreview-2062190669

From lmesnik at openjdk.org  Fri May 17 02:08:34 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 May 2024 02:08:34 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v2]
In-Reply-To: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
Message-ID: <qkH_2I5ahbENex6P4VQTfHVGxoDG3gDvp-D01Tofos4=.a836ef0b-7452-4f32-a268-5e0c43ae3c66@github.com>

> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
> 
> It happens when thread_name is set for tracing from jvmti functions.
> See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
> 
> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
> 
> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
> 
> Verified by running jvmti/jdi/jdb tests with tracing enabled.

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

 - copyrights updated.
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8332259
 - include updated.
 - 8332259

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19275/files
  - new: https://git.openjdk.org/jdk/pull/19275/files/a2b1942b..c534c91b

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

  Stats: 30226 lines in 654 files changed: 18294 ins; 7842 del; 4090 mod
  Patch: https://git.openjdk.org/jdk/pull/19275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19275/head:pull/19275

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

From qamai at openjdk.org  Fri May 17 03:52:01 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 17 May 2024 03:52:01 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
Message-ID: <5OI8D0PhkM19awFsxnm6RTlJkaDxkUyvW75D3q-wK0Q=.a2a0262e-9d3c-4380-aafd-e6b7cfc4393a@github.com>

On Fri, 17 May 2024 00:43:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
>> 
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
>> This update is to make it clear that `nullptr` is C programming language `null` pointer.
>> 
>> I think we do not need a CSR for this fix.
>> 
>> Testing: N/A (not needed)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: corrected the nullptr clarification

src/hotspot/share/prims/jvmti.xml line 1007:

> 1005:     explicitly deallocate. This is indicated in the individual <jvmti/>
> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
> 1007:     returned as a null pointer (C <code>NULL</code> or C++ <code>nullptr</code>).

This may be a little unnecessary rigor, but I believe that `nullptr` is not a null pointer. `nullptr` is the pointer literal that can be implicitly converted to a null pointer value of any pointer type and any pointer to member type. And I think the thing returned here is a null pointer, not `nullptr`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1604313245

From kbarrett at openjdk.org  Fri May 17 04:37:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 17 May 2024 04:37:01 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
 <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>
Message-ID: <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>

On Fri, 17 May 2024 02:00:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But this clarification doesn't actually clarify that the rest of the spec uses `nullptr`. Based on the proposed wording I would expect things like:
> 
> ```
> The function may return <code>nullptr</code>
> ```
> 
> to say
> 
> ```
> The function may return a null pointer
> ```

Looking at this again, I think I agree with @dholmes-ora .

Some of the relevant places are text, and should be using "null pointer".
Some are example code or the like.  Those should be using NULL rather than
nullptr, since we have this text early on:

"Unless otherwise stated, all examples and declarations in this
specification use the C language."

I didn't find any that were described as C++ rather than C.

So JDK-8324680 was somewhat mistaken about what needed to be done, and what
was done.

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

PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2116606245

From alanb at openjdk.org  Fri May 17 04:50:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 04:50:01 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <k0WQywNEN45zwk5entj15wq5g-tWrbr3Y733PTozoVY=.5ff79f1a-1ab3-43de-849d-943b120871e9@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <KD9R-pWTbNmk2X_DXiILVZWc-njmTKsT9eM3bXs8hL0=.31b72eff-aa4c-4585-bfeb-b666f27c9925@github.com>
 <k0WQywNEN45zwk5entj15wq5g-tWrbr3Y733PTozoVY=.5ff79f1a-1ab3-43de-849d-943b120871e9@github.com>
Message-ID: <cl7GlE_WaUr0moi3xGlwunaU3EvLVWtJ89d-lX9la24=.fb301202-17c8-48c5-ae9a-a103b8ce8524@github.com>

On Fri, 17 May 2024 00:38:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 1008:
>> 
>>> 1006:     function descriptions.  Empty lists, arrays, sequences, etc are
>>> 1007:     returned as <code>nullptr</code> which is C programming language
>>> 1008:     <code>null</code> pointer.
>> 
>> Perhaps instead something like
>> 
>> "returned as a null pointer (C <code>NULL</code> or C++ <code>nullptr</code>)."
>> 
>> "null pointer" is the generic phrase used in both the C and C++ standards.
>
> Thank you, Kim. I like this suggestion. Updated now.

That part looks okay but I think all the parameters and error descriptions changed by JDK-8324680 will now need to change to use "null" instead of "nullptr".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1604344850

From dholmes at openjdk.org  Fri May 17 05:55:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 May 2024 05:55:03 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v2]
In-Reply-To: <qkH_2I5ahbENex6P4VQTfHVGxoDG3gDvp-D01Tofos4=.a836ef0b-7452-4f32-a268-5e0c43ae3c66@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <qkH_2I5ahbENex6P4VQTfHVGxoDG3gDvp-D01Tofos4=.a836ef0b-7452-4f32-a268-5e0c43ae3c66@github.com>
Message-ID: <GN9gc9GXemPAK2Y_95orlY9KmuWbGFK_IwrZUoCRNuI=.15967f19-c088-43cc-b871-6ce614abbdea@github.com>

On Fri, 17 May 2024 02:08:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - copyrights updated.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8332259
>  - include updated.
>  - 8332259

I have to wonder whether this solution will potentially cause problems because the code will now block for safepoints. We could fallback to `Thread::name()` if the current thread is in-native.

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

PR Review: https://git.openjdk.org/jdk/pull/19275#pullrequestreview-2062389545

From iwalulya at openjdk.org  Fri May 17 06:10:05 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 17 May 2024 06:10:05 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
Message-ID: <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>

On Fri, 10 May 2024 08:55:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
>> 
>> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into s1-do-collect
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - merge
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - s1-do-collect

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/serial/serialHeap.cpp line 557:

> 555:     return result;
> 556:   }
> 557: 

Would be nice to add a comment here to indicate that the previous collection could have shrunk the heap.

src/hotspot/share/gc/serial/serialHeap.cpp line 714:

> 712: 
> 713: void SerialHeap::do_full_collection_no_gc_locker(bool clear_all_soft_refs) {
> 714:   IsSTWGCActiveMark gc_active_mark;

`IsSTWGCActiveMark active_gc_mark;`in`do_young_collection_no_gc_locker`, just choose one and be consistent with it

src/hotspot/share/gc/serial/serialHeap.cpp line 907:

> 905: 
> 906: void SerialHeap::print_tracing_info() const {
> 907:  // Nothing

What is the `Nothing` supposed to convey here?

src/hotspot/share/gc/serial/serialHeap.hpp line 117:

> 115:   void do_full_collection_no_gc_locker(bool clear_all_soft_refs);
> 116: 
> 117:   void collect_at_safepoint_no_gc_locker(bool full);

I am not very convinced by the naming of the methods with the "no_gc_locker" constraint.  But I guess it is following same convention as "*at_safepoint" method naming.

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

PR Review: https://git.openjdk.org/jdk/pull/19056#pullrequestreview-2062384283
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604380445
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604389765
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604390627
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604388902

From ayang at openjdk.org  Fri May 17 07:26:09 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 May 2024 07:26:09 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
 <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>
Message-ID: <SZVlB7geQ-gGNTVU8Iz1F4gCmfrRuJZqFcpHpK5apdo=.3621a569-30c5-48fb-8ba8-a3a7895bce6a@github.com>

On Fri, 17 May 2024 06:02:31 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'master' into s1-do-collect
>>  - review
>>  - Merge branch 'master' into s1-do-collect
>>  - merge
>>  - review
>>  - Merge branch 'master' into s1-do-collect
>>  - s1-do-collect
>
> src/hotspot/share/gc/serial/serialHeap.cpp line 907:
> 
>> 905: 
>> 906: void SerialHeap::print_tracing_info() const {
>> 907:  // Nothing
> 
> What is the `Nothing` supposed to convey here?

To emphasize that this empty method is intentional, inspired by `ZCollectedHeap::print_tracing_info`.

> src/hotspot/share/gc/serial/serialHeap.hpp line 117:
> 
>> 115:   void do_full_collection_no_gc_locker(bool clear_all_soft_refs);
>> 116: 
>> 117:   void collect_at_safepoint_no_gc_locker(bool full);
> 
> I am not very convinced by the naming of the methods with the "no_gc_locker" constraint.  But I guess it is following same convention as "*at_safepoint" method naming.

How about calling them `try_x` and `x` for the public and private API, respectively, e.g. `try_do_full_collection` and `do_full_collection`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604459781
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604462152

From iwalulya at openjdk.org  Fri May 17 07:26:10 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 17 May 2024 07:26:10 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <SZVlB7geQ-gGNTVU8Iz1F4gCmfrRuJZqFcpHpK5apdo=.3621a569-30c5-48fb-8ba8-a3a7895bce6a@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
 <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>
 <SZVlB7geQ-gGNTVU8Iz1F4gCmfrRuJZqFcpHpK5apdo=.3621a569-30c5-48fb-8ba8-a3a7895bce6a@github.com>
Message-ID: <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com>

On Fri, 17 May 2024 07:17:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialHeap.cpp line 907:
>> 
>>> 905: 
>>> 906: void SerialHeap::print_tracing_info() const {
>>> 907:  // Nothing
>> 
>> What is the `Nothing` supposed to convey here?
>
> To emphasize that this empty method is intentional, inspired by `ZCollectedHeap::print_tracing_info`.

Then better to keep the verb in the comment ` // Does nothing`

>> src/hotspot/share/gc/serial/serialHeap.hpp line 117:
>> 
>>> 115:   void do_full_collection_no_gc_locker(bool clear_all_soft_refs);
>>> 116: 
>>> 117:   void collect_at_safepoint_no_gc_locker(bool full);
>> 
>> I am not very convinced by the naming of the methods with the "no_gc_locker" constraint.  But I guess it is following same convention as "*at_safepoint" method naming.
>
> How about calling them `try_x` and `x` for the public and private API, respectively, e.g. `try_do_full_collection` and `do_full_collection`?

I prefer that to the "no_gc_locker" emphasizing names

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604466593
PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604465894

From ayang at openjdk.org  Fri May 17 07:44:29 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 May 2024 07:44:29 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v7]
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <vzzO9EcDprUddQ1qlc6O4t7cWUdB8JAsYj5PDpDW92k=.cfb30850-f22c-4920-9fd9-8a53b3d5d366@github.com>

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - review
 - Merge branch 'master' into s1-do-collect
 - Merge branch 'master' into s1-do-collect
 - review
 - Merge branch 'master' into s1-do-collect
 - merge
 - review
 - Merge branch 'master' into s1-do-collect
 - s1-do-collect

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

Changes: https://git.openjdk.org/jdk/pull/19056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19056&range=06
  Stats: 566 lines in 15 files changed: 125 ins; 356 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19056/head:pull/19056

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

From ayang at openjdk.org  Fri May 17 07:44:29 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 May 2024 07:44:29 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
 <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>
 <SZVlB7geQ-gGNTVU8Iz1F4gCmfrRuJZqFcpHpK5apdo=.3621a569-30c5-48fb-8ba8-a3a7895bce6a@github.com>
 <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com>
Message-ID: <nL96Vu5ZonNAaAEPQOVIjPNZW-mPypjW420yOxOK6Ok=.665d0ddd-88b3-4356-b863-99e92eabdcdf@github.com>

On Fri, 17 May 2024 07:22:36 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> How about calling them `try_x` and `x` for the public and private API, respectively, e.g. `try_do_full_collection` and `do_full_collection`?
>
> I prefer that to the "no_gc_locker" emphasizing names

I can do that for `try_collect_at_safepoint`, but `SerialHeap::do_full_collection` is an API from `CollectedHeap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604485388

From iwalulya at openjdk.org  Fri May 17 07:44:29 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 17 May 2024 07:44:29 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v6]
In-Reply-To: <nL96Vu5ZonNAaAEPQOVIjPNZW-mPypjW420yOxOK6Ok=.665d0ddd-88b3-4356-b863-99e92eabdcdf@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <NaLZVn2uF5Zlhrd2W-qII1silaB_4wUtrurUw66T4Jc=.0241d28f-5add-4dba-a49b-11037b6c7d7d@github.com>
 <QB1rLH8ISuSRmFpLUlgvtNl_AdeFw23xbEgPfAQnVms=.8d3a4027-83f6-4b94-8987-6792235e3f8b@github.com>
 <SZVlB7geQ-gGNTVU8Iz1F4gCmfrRuJZqFcpHpK5apdo=.3621a569-30c5-48fb-8ba8-a3a7895bce6a@github.com>
 <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com>
 <nL96Vu5ZonNAaAEPQOVIjPNZW-mPypjW420yOxOK6Ok=.665d0ddd-88b3-4356-b863-99e92eabdcdf@github.com>
Message-ID: <shpLwZvRuowrArie4Jn1HD1SlThgM136EBIUV30dRGI=.e4bc8842-8ae1-46c2-9c5d-6e4f7a57f6e5@github.com>

On Fri, 17 May 2024 07:39:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I prefer that to the "no_gc_locker" emphasizing names
>
> I can do that for `try_collect_at_safepoint`, but `SerialHeap::do_full_collection` is an API from `CollectedHeap`.

yeah, i only meant change those that are not "override" and have the "no_gclocker" postfix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19056#discussion_r1604487661

From iwalulya at openjdk.org  Fri May 17 08:06:12 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 17 May 2024 08:06:12 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v7]
In-Reply-To: <vzzO9EcDprUddQ1qlc6O4t7cWUdB8JAsYj5PDpDW92k=.cfb30850-f22c-4920-9fd9-8a53b3d5d366@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <vzzO9EcDprUddQ1qlc6O4t7cWUdB8JAsYj5PDpDW92k=.cfb30850-f22c-4920-9fd9-8a53b3d5d366@github.com>
Message-ID: <bstCZN5wYn_RXyklupz2vtZqYlp1HxbmwLC26g2ospc=.f8e0c9b4-6e7e-4a76-ba83-26f232eb6641@github.com>

On Fri, 17 May 2024 07:44:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
>> 
>> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - Merge branch 'master' into s1-do-collect
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - merge
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - s1-do-collect

Looks good! Thanks for the cleanup.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19056#pullrequestreview-2062603522

From ayang at openjdk.org  Fri May 17 09:12:25 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 May 2024 09:12:25 GMT
Subject: RFR: 8331557: Serial: Refactor SerialHeap::do_collection [v7]
In-Reply-To: <vzzO9EcDprUddQ1qlc6O4t7cWUdB8JAsYj5PDpDW92k=.cfb30850-f22c-4920-9fd9-8a53b3d5d366@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
 <vzzO9EcDprUddQ1qlc6O4t7cWUdB8JAsYj5PDpDW92k=.cfb30850-f22c-4920-9fd9-8a53b3d5d366@github.com>
Message-ID: <jivb6OcIr9g8Vdns4iKH7PnWwkCe_FSDF-5uu1f1r2Y=.461ab8f2-f31e-419e-bf76-aaaa901be417@github.com>

On Fri, 17 May 2024 07:44:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
>> 
>> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - Merge branch 'master' into s1-do-collect
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - merge
>  - review
>  - Merge branch 'master' into s1-do-collect
>  - s1-do-collect

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19056#issuecomment-2117095015

From ayang at openjdk.org  Fri May 17 09:12:26 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 May 2024 09:12:26 GMT
Subject: Integrated: 8331557: Serial: Refactor SerialHeap::do_collection
In-Reply-To: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
References: <quIudQEgqlLuSrhMw27yZ1tc3KkcoP5dJBNGSrQ_UpI=.a6c0f329-be3d-449f-941f-15950446cb44@github.com>
Message-ID: <42-vFtR8If6ZyRbW1G5AL__9eFqxCl-FMOA-4g8NTqE=.25018359-ed9c-4a6f-9ac1-624095cb595c@github.com>

On Thu, 2 May 2024 10:48:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> It's probably easier to read the new code directly. The two classes in `serialVMOperations` serve as entrance points to invoke young/full GCs. Some previously hidden decisions are made more obvious, e.g. if a young-gc fails (or will probablly fail), fallback to full-gc.
> 
> Additionally, `StatRecord` is removed, because this kind of info-aggregation should be done outsite VM (by third-party tool).
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: f1ce9b0e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1ce9b0ecce9b506f5bf7a66fcf03c93b9ae8fed
Stats:     566 lines in 15 files changed: 125 ins; 356 del; 85 mod

8331557: Serial: Refactor SerialHeap::do_collection

Reviewed-by: gli, iwalulya

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

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

From alanb at openjdk.org  Fri May 17 09:34:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:34:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <9oh0XZoux2OKBke0T-hr6CS9OsuDD6Wk1HdQdPu2YyY=.1d9a2a75-cb80-498c-86f9-da457669e3e8@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/foreign/package-info.java line 170:

> 168:  * the special value {@code ALL-UNNAMED} can be used). Access to restricted methods
> 169:  * from modules not listed by that option is deemed <em>illegal</em>. Clients can
> 170:  * control how illegal access to restricted method is handled, using the command line

I assume this should be "to a restricted method is handled" or "to restricted methods are handled", either would work here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950

From alanb at openjdk.org  Fri May 17 09:40:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:40:21 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <W-o6qMpByBf7fBVE1h-_fFwlI6bTAsGw-4R24hQbBeE=.0a4838db-f222-4155-8bfb-2f8cf52b4eef@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288:

> 286:      * throw exception depending on the configuration.
> 287:      */
> 288:     void ensureNativeAccess(Module m, Class<?> owner, String methodName, Class<?> currentClass, boolean jni);

It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767

From apangin at openjdk.org  Fri May 17 09:43:12 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 17 May 2024 09:43:12 GMT
Subject: Integrated: 8332327: Return _methods_jmethod_ids field back in
 VMStructs
In-Reply-To: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
References: <Jpr3UOxVjFJRtmR4hVip4f--zDlYqBzqbJRnhYatyik=.d2ac219e-d6e1-435d-a2d4-8d5271c4405b@github.com>
Message-ID: <txwAZs3-4BVSjgTA3lMJK74OomxJ8E777gdqJ4lZi3k=.e5fee733-140f-460f-a6e6-6324c6e214fa@github.com>

On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> ) `InstanceKlass::_methods_jmethod_ids` field from VMStructs.
> 
> This broke [async-profiler](https://github.com/async-profiler/async-profiler/), since the profiler needs this field to obtain jmethodID in some corner cases.
> 
> There was no actual need for removal, as the field is still there in InstanceKlass. So, I propose to return the field back to restore the broken functionality of async-profiler. This is a no risk change, because it only exports an offset of one field and does not affect the JVM otherwise.

This pull request has now been integrated.

Changeset: d84a8fd8
Author:    Andrei Pangin <apangin at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d84a8fd8762fe9448e73d75ec9dc8c4876b1a709
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8332327: Return _methods_jmethod_ids field back in VMStructs

Reviewed-by: cjplummer, sspitsyn, coleenp, shade

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

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

From alanb at openjdk.org  Fri May 17 09:44:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:44:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <K-ddELjw1PrhIpxriH8mimHSS4zSSzpt-IAoh7D5f3A=.e9b76a6b-b6cb-4e63-93cc-5b06f6aee862@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/ClassLoader.java line 2448:

> 2446:      * Invoked in the VM class linking code.
> 2447:      */
> 2448:     static long findNative(ClassLoader loader, Class<?> clazz, String entryName, String javaName) {

I think this is another place where `@param` descriptions would help as it's not immediately clear that "javaName" is a method name.

src/java.base/share/classes/java/lang/Runtime.java line 39:

> 37: 
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;

Runtime has been touched for a while so you'll need to bump the copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293

From alanb at openjdk.org  Fri May 17 09:48:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:48:13 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <xjxqMo73h5zMqu-HCClmiqySodIWBCGCWfjMa_Y5pa0=.0d5904a7-f027-49b1-bd33-e49ab547551a@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

This looks good. Just a few minor comments where future maintainers might appreciate comments that describe parameters.

src/java.base/share/classes/java/lang/Module.java line 332:

> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 if (jni) {
> 332:                     System.err.printf("""

System.err may change in a running VM. It may be that we will need to change this at some point to use its initial setting. Not suggesting we changing it now but we might have to re-visit this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749

From dfuchs at openjdk.org  Fri May 17 10:18:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 May 2024 10:18:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
Message-ID: <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>

On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add an 'also'
>  - typo

Marked as reviewed by dfuchs (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 979:

> 977:      * @throws IOException if a general communication exception occurred.
> 978:      * @throws UnsupportedOperationException if {@code delegationSubjects}
> 979:      * contains any non-null values.

Suggestion:

     * @throws UnsupportedOperationException if {@code delegationSubjects}
     * is non-null and contains any non-null values.

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

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2062912013
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604707244

From alanb at openjdk.org  Fri May 17 10:38:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 10:38:04 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
Message-ID: <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>

On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add an 'also'
>  - typo

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:

> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 960:      * array is also accepted for compatibility reasons, which must not
> 961:      * contain any non-null entries.

The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604740107

From mcimadamore at openjdk.org  Fri May 17 13:23:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:23:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
 <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
Message-ID: <GLNx0ptAp6dY9BORWHEv6XnKqoRWn_QejEmKQ6iY540=.4a5fe98e-b069-4250-b9d2-bbc8f9b89841@github.com>

On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add note on --illegal-native-access default value in the launcher help
>
> src/java.base/share/classes/java/lang/System.java line 2023:
> 
>> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
>> 2022:      * @throws     IllegalCallerException If the caller is in a module that
>> 2023:      *             does not have native access enabled.
> 
> The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

I'll fix this. Note that in `ModuleLayer.Controller`, all `@throws` start with capital letter, which is probably where I copied/pasted this from. I'll fix all, except for `ModuleLayer` where, for consistency, I think upper case is better.

> src/java.base/share/man/java.1 line 587:
> 
>> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
>> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
>> 587: command-line option.
> 
> "This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 
> 
> This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

I've simplified the text to:


This mode disables illegal native access. That is, any illegal native access causes an `IllegalCallerException`.
This mode will become the default in a future release.


I think it's not necessary to state again the dependency on `--enable-native-access` as we already defined what "illegal native access" means.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604994928
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604993505

From mcimadamore at openjdk.org  Fri May 17 13:38:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:38:25 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/3a0db276..789bdf48

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

  Stats: 28 lines in 10 files changed: 8 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

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

From kevinw at openjdk.org  Fri May 17 16:01:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 May 2024 16:01:24 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v4]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <7gg2ucNT8hZX7N2ivvIjjBWPNTT2yOzYb72f7TvDJzs=.24c63b3c-dec6-49fe-9876-30e1c2d6800f@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  UOE doc correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/68c791e7..4e8f84ec

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

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

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

From kevinw at openjdk.org  Fri May 17 16:01:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 May 2024 16:01:25 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>
Message-ID: <uoOuWt-bp7ErFPu606Wni2deBjLkk2VQ7B7Rmlw8kI8=.085e39cf-02c3-4b96-9f0f-924f2e98cd6f@github.com>

On Fri, 17 May 2024 10:14:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add an 'also'
>>  - typo
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 979:
> 
>> 977:      * @throws IOException if a general communication exception occurred.
>> 978:      * @throws UnsupportedOperationException if {@code delegationSubjects}
>> 979:      * contains any non-null values.
> 
> Suggestion:
> 
>      * @throws UnsupportedOperationException if {@code delegationSubjects}
>      * is non-null and contains any non-null values.

Yes, thanks well spotted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1605235219

From lmesnik at openjdk.org  Fri May 17 16:46:29 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 May 2024 16:46:29 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v3]
In-Reply-To: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
Message-ID: <AT8_bJuS0Bgr_fieEo6KK8jUiW_cW6dCZ2MR6FI1erA=.b399516e-d892-4876-b74a-96a4d990d6a9@github.com>

> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
> 
> It happens when thread_name is set for tracing from jvmti functions.
> See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
> 
> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
> 
> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
> 
> Verified by running jvmti/jdi/jdb tests with tracing enabled.

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

  don't change state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19275/files
  - new: https://git.openjdk.org/jdk/pull/19275/files/c534c91b..f8fd4744

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

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

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

From lmesnik at openjdk.org  Fri May 17 16:56:04 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 May 2024 16:56:04 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v2]
In-Reply-To: <GN9gc9GXemPAK2Y_95orlY9KmuWbGFK_IwrZUoCRNuI=.15967f19-c088-43cc-b871-6ce614abbdea@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <qkH_2I5ahbENex6P4VQTfHVGxoDG3gDvp-D01Tofos4=.a836ef0b-7452-4f32-a268-5e0c43ae3c66@github.com>
 <GN9gc9GXemPAK2Y_95orlY9KmuWbGFK_IwrZUoCRNuI=.15967f19-c088-43cc-b871-6ce614abbdea@github.com>
Message-ID: <tAOhmcK0IsymfPpe4yTLYNZQnkJoRR0lNwKF8bmHVp8=.e8d362eb-bec8-4ee4-bf36-c55e73f1ced4@github.com>

On Fri, 17 May 2024 05:52:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I have to wonder whether this solution will potentially cause problems because the code will now block for safepoints. We could fallback to `Thread::name()` if the current thread is in-native.

Thanks for feedback. Here is the update.

I've updated the safe_get_thread_name() to not change thread state. 

In  "jvmtiEnter.xsl" functions the thread name is s read once before the transition happened and re-used then. 
So I updated the tracing to 're-read' if the transition to VM happened to update the thread name once it became known.

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

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2118004152

From cjplummer at openjdk.org  Fri May 17 19:32:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 May 2024 19:32:31 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix a couple of minor typos in comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19044/files
  - new: https://git.openjdk.org/jdk/pull/19044/files/c3bd1716..33fcea3e

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

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

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

From cjplummer at openjdk.org  Fri May 17 19:32:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 May 2024 19:32:31 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <Hbd9xr14HDxTyrhkGXttxAwfME9Ntl1wCyoelpgS314=.be9ef44a-4278-450c-a8fa-50081cd1c5c1@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
 <Hbd9xr14HDxTyrhkGXttxAwfME9Ntl1wCyoelpgS314=.be9ef44a-4278-450c-a8fa-50081cd1c5c1@github.com>
Message-ID: <QiMfzOxXd7rcEA4MMGHb-CNT_2R2ypnvU6G2zxuNGaA=.6b68a2c3-1676-4516-a90f-63f7b6fe3aed@github.com>

On Thu, 16 May 2024 17:37:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is that "then popFrameEventLock second"
> 
Yes. I'll fix.

> Drawing these out in two columns I can't see a deadlock either 8-)

Ironically right now I'm looking at a very rare deadlock that involves this code. It doesn't seem to happen when I disabled ranked locking. It might be instigated by the dbgRawMonitor that ranked locking uses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1603965727

From amenkov at openjdk.org  Fri May 17 20:20:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 May 2024 20:20:02 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
Message-ID: <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com>

On Thu, 2 May 2024 20:58:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 656:
>> 
>>> 654:     commonRef_lock();
>>> 655:     if (gdata->rankedMonitors) {
>>> 656:         dbgRawMonitor_lock();
>> 
>> What is this call for? I think dbgRawMonitor_lock/dbgRawMonitor_unlock should not be used outside of util.c (I'd remove them from util.h)
>
> After calling getLocks(), there may still be attempts to enter locks. The locks should already be held. I filed [JDK-8330193](https://bugs.openjdk.org/browse/JDK-8330193) to assert that. However, even when entering an already entered lock, we still need to grab dbgRawMonitor. I found that out the hard way when there were deadlocks on dbgRawMonitor because it was not entered it here.

I think expose dbgRawMonitor outside of util.c is wrong (and use gdata->rankedMonitors outside of utils.c too).
If it's really required, it would be better to add functions to disable/enable monitor locks.
But I still don't understand why we need this (and what is JDK-8330193 about)
Both JVMTI raw monitors and DebugRawMonitor support re-entrance, so this thread may enter the locks again (and other threads will wait for the locks if they try to enter them).
And I don't see how we can get deadlocks on dbgRawMonitor, could you please elaborate on that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605484995

From amenkov at openjdk.org  Fri May 17 20:20:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 May 2024 20:20:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <iRFbdas1EjvfgmqEqz5WyTGci7VFHdO5vtJWAgQJ9NE=.2beff216-4946-4d9d-a53b-33be79363433@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <iRFbdas1EjvfgmqEqz5WyTGci7VFHdO5vtJWAgQJ9NE=.2beff216-4946-4d9d-a53b-33be79363433@github.com>
Message-ID: <-Ho-NMofYJzkvKpfdUrOOq0RqLamcGGtrSm3MFy2cIs=.d3b334f2-0d6c-4e77-b91c-63a463790e28@github.com>

On Thu, 9 May 2024 06:10:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Flip rank order. Some cleanup and better comments for verifyMonitorRank().

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1145:

> 1143:  */
> 1144: 
> 1145: static jrawMonitorID dbgRawMonitor;

As the monitor is used to synchronize access to dbg_monitors array, maybe rename it to something like dbg_monitors_lock?

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1276:

> 1274: 
> 1275: static void
> 1276: assertIsCurrentThread(JNIEnv *env, jthread thread, jthread current_thread)

The function gets both threads as arguments, I think `assertIsSameThread` would be more correct name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605494862
PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605498977

From sspitsyn at openjdk.org  Fri May 17 20:43:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 May 2024 20:43:00 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
 <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>
 <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>
Message-ID: <q-X-IQwpbU2ZjDGbUDplAF11Yjk27i_UbBnZihf0uiw=.0abb99f9-8f4d-49a3-a1dd-bc90a72f897f@github.com>

On Fri, 17 May 2024 04:34:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> So JDK-8324680 was somewhat mistaken about what needed to be done, and what
was done.

The `jvmti.xml` is used to generate several things with the XSL scripts:
 - JVMTI spec (`jvm.html`)
 - JVMTI api (`jvmti.h`)
 - `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`
 
 In fact, it is pretty tricky to separate these usage aspects of `nullptr` or `NULL`.
 One of the approaches is to undo the [JDK-8324680](https://bugs.openjdk.org/browse/JDK-8324680).
 Please, let me know if you prefer this path.

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

PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2118354928

From lmesnik at openjdk.org  Fri May 17 22:31:32 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 May 2024 22:31:32 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
Message-ID: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>

> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
> 
> It happens when thread_name is set for tracing from jvmti functions.
> See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
> 
> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
> 
> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
> 
> Verified by running jvmti/jdi/jdb tests with tracing enabled.

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

  wrong thread state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19275/files
  - new: https://git.openjdk.org/jdk/pull/19275/files/f8fd4744..12ddfca2

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

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

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

From cjplummer at openjdk.org  Fri May 17 23:01:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 May 2024 23:01:02 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com>
Message-ID: <e-ZfC-GYg_rnsDIIZb8mEZcTsobjGTiJPn3hZVczcKU=.cdc59c25-8117-422b-a7a8-910708530701@github.com>

On Fri, 17 May 2024 19:52:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> After calling getLocks(), there may still be attempts to enter locks. The locks should already be held. I filed [JDK-8330193](https://bugs.openjdk.org/browse/JDK-8330193) to assert that. However, even when entering an already entered lock, we still need to grab dbgRawMonitor. I found that out the hard way when there were deadlocks on dbgRawMonitor because it was not entered it here.
>
> I think expose dbgRawMonitor outside of util.c is wrong (and use gdata->rankedMonitors outside of utils.c too).
> If it's really required, it would be better to add functions to disable/enable monitor locks.
> But I still don't understand why we need this (and what is JDK-8330193 about)
> Both JVMTI raw monitors and DebugRawMonitor support re-entrance, so this thread may enter the locks again (and other threads will wait for the locks if they try to enter them).
> And I don't see how we can get deadlocks on dbgRawMonitor, could you please elaborate on that.

The comment above getLocks() pretty much explains it. Before doing any thread suspension we can't allow any other thread to hold a lock that might be needed during suspension. This is why getLocks() is used to grab all these locks in advanced. If they were not grabbed in advanced and one of the locks was held by another thread that got suspended, then eventually the current thread (the one that initiated the thread suspension) would block on the suspended thread, which means it would never get resumed, so we have a deadlock. If we don't include dbgRawMonitor in this set of locks and we suspend a thread while it holds it, this prevents the current thread from doing a debugMonitorEnter on any lock, even ones it already holds. Note we can't check if the current thread owns a lock without grabbing dbgRawMonitor. In fact the main purpose of dbgRawMonitor is to allow the current thread to check if it owns the monitor.

I don't disagree that it's a bit of a wart that dbgRawMonitor is exposed in this manner. I just don't see a way around it. I can hide gdata->rankedMonitors in dbgRawMonitor_lock/unlock() if you want, but I can't see of way to not export dbgRawMonitor_lock/unlock() in some fashion, possibly with a different name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605602137

From cjplummer at openjdk.org  Fri May 17 23:01:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 May 2024 23:01:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v6]
In-Reply-To: <-Ho-NMofYJzkvKpfdUrOOq0RqLamcGGtrSm3MFy2cIs=.d3b334f2-0d6c-4e77-b91c-63a463790e28@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <iRFbdas1EjvfgmqEqz5WyTGci7VFHdO5vtJWAgQJ9NE=.2beff216-4946-4d9d-a53b-33be79363433@github.com>
 <-Ho-NMofYJzkvKpfdUrOOq0RqLamcGGtrSm3MFy2cIs=.d3b334f2-0d6c-4e77-b91c-63a463790e28@github.com>
Message-ID: <ty3NaEzPGpPgMI7wQ36jj2jSni5vsCT_GdCBXCoYK4A=.c41dd8f0-16e3-457a-8122-ce06d165af10@github.com>

On Fri, 17 May 2024 20:03:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Flip rank order. Some cleanup and better comments for verifyMonitorRank().
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1145:
> 
>> 1143:  */
>> 1144: 
>> 1145: static jrawMonitorID dbgRawMonitor;
> 
> As the monitor is used to synchronize access to dbg_monitors array, maybe rename it to something like dbg_monitors_lock?

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605602835

From amenkov at openjdk.org  Sat May 18 00:53:21 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 18 May 2024 00:53:21 GMT
Subject: RFR: 8331683: Clean up GetCarrierThread
Message-ID: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>

JVMTI GetCarrierThread extension function was introduced by loom for testing.
It's used by several tests in hotspot/jtreg/serviceability.

Testings: tier1..tier6

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Sat May 18 01:15:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 18 May 2024 01:15:08 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <e-ZfC-GYg_rnsDIIZb8mEZcTsobjGTiJPn3hZVczcKU=.cdc59c25-8117-422b-a7a8-910708530701@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <tTuBdXCtKx-rOSSc3MrciioENQ6n4T7_oavtNb4LuJU=.c587c948-d49c-4099-9a68-331b4a8109ca@github.com>
 <eeRcKMfcCRU4v6pvaRF--t4iB3IKh8E3JuBOtV_cewg=.c304c980-18d0-4353-94ae-1939ef0bdb8d@github.com>
 <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com>
 <e-ZfC-GYg_rnsDIIZb8mEZcTsobjGTiJPn3hZVczcKU=.cdc59c25-8117-422b-a7a8-910708530701@github.com>
Message-ID: <0HXJPQWdMRSKIcTjYTovSy7Gybekqpga4xQ55Lwc8c4=.57042c01-8bae-4d43-bfe7-e7b1238913e9@github.com>

On Fri, 17 May 2024 22:56:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I think expose dbgRawMonitor outside of util.c is wrong (and use gdata->rankedMonitors outside of utils.c too).
>> If it's really required, it would be better to add functions to disable/enable monitor locks.
>> But I still don't understand why we need this (and what is JDK-8330193 about)
>> Both JVMTI raw monitors and DebugRawMonitor support re-entrance, so this thread may enter the locks again (and other threads will wait for the locks if they try to enter them).
>> And I don't see how we can get deadlocks on dbgRawMonitor, could you please elaborate on that.
>
> The comment above getLocks() pretty much explains it. Before doing any thread suspension we can't allow any other thread to hold a lock that might be needed during suspension. This is why getLocks() is used to grab all these locks in advanced. If they were not grabbed in advanced and one of the locks was held by another thread that got suspended, then eventually the current thread (the one that initiated the thread suspension) would block on the suspended thread, which means it would never get resumed, so we have a deadlock. If we don't include dbgRawMonitor in this set of locks and we suspend a thread while it holds it, this prevents the current thread from doing a debugMonitorEnter on any lock, even ones it already holds. Note we can't check if the current thread owns a lock without grabbing dbgRawMonitor. In fact the main purpose of dbgRawMonitor is to allow the current thread to check if it owns the monitor.
> 
> I don't disagree that it's a bit of a wart that dbgRawMonitor is exposed in this manner. I just don't see a way around it. I can hide gdata->rankedMonitors in dbgRawMonitor_lock/unlock() if you want, but I can't see of way to not export dbgRawMonitor_lock/unlock() in some fashion, possibly with a different name.

Thank you for the explanation, I missed that threads can be suspended during checking for ownerThread.
With this lock no other thread (except current) can enter/exit/wait any monitor, but I suppose it's ok as dbgRawMonitor is locked only while current thread suspends required thread(s)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1605637099

From duke at openjdk.org  Sat May 18 09:07:18 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 18 May 2024 09:07:18 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v12]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <jndqQQhaWY-AdOhgwSqkFxJeAEulSap-QrT9OiB4GQc=.cfa532f4-6894-4946-b687-aafd82268dbf@github.com>

> follow up 8267941

Lei Zaakjyu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  restore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/dafdc775..c240897a

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

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

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

From jpai at openjdk.org  Sat May 18 11:43:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 May 2024 11:43:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <_4CgX7Ojzb5QH2sJ4k2fDgfz_zba03l_4feYaVyzhl0=.a6128ce8-56c3-4b71-a0e3-cf48c9b68c3e@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2064736036

From nbenalla at openjdk.org  Sun May 19 16:00:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 19 May 2024 16:00:27 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi` to
 package-info.java
Message-ID: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>

Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
The conversion was done in-place, only renaming it in git.
I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.

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

Commit messages:
 - remove whitespace
 - - convert package.html to package-info.java

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

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

From nbenalla at openjdk.org  Sun May 19 16:00:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 19 May 2024 16:00:27 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <NwFQVFf4xlYKKkYh7RRBNFBZWU86ShxlM8SxdtjEIgQ=.87d28e5e-16da-4fd6-97aa-a9e0b03910d8@github.com>

On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.

sorry about the force push, had to.

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

PR Comment: https://git.openjdk.org/jdk/pull/19263#issuecomment-2119024503

From alanb at openjdk.org  Sun May 19 18:50:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 May 2024 18:50:08 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <i4qyeHY6f2zbEnY4IE_a2ZMbaBvpITvVD9pXoGTerDI=.90c09f8c-4968-43e7-b7a8-e06ded699ef7@github.com>

On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 26:

> 24:  */
> 25: 
> 26: /**

I assume you'll need to prepend each line with `*` too, which has the side effect of making it appear that every line is changed but I think we just need to get over that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1606084149

From nbenalla at openjdk.org  Sun May 19 19:08:01 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 19 May 2024 19:08:01 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java
In-Reply-To: <i4qyeHY6f2zbEnY4IE_a2ZMbaBvpITvVD9pXoGTerDI=.90c09f8c-4968-43e7-b7a8-e06ded699ef7@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <i4qyeHY6f2zbEnY4IE_a2ZMbaBvpITvVD9pXoGTerDI=.90c09f8c-4968-43e7-b7a8-e06ded699ef7@github.com>
Message-ID: <F4xM2SA2h5Suu3ZFTWdJH6gh5MNLlRc79EHAdvcKm1w=.2a80b20d-6bdd-44ec-9d18-f2be83de9e78@github.com>

On Sun, 19 May 2024 18:47:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
>> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
>> The conversion was done in-place, only renaming it in git.
>> 
>> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
>> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: /**
> 
> I assume you'll need to prepend each line with `*` too, which has the side effect of making it appear that every line is changed but I think we just need to get over that.

Doing that makes git think it's a new file, rather than a rename.
I was doing this in [a26ee08](https://github.com/openjdk/jdk/commit/a26ee085b5184d62a879f88f6cca6780e0e4e472) and removed it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1606086468

From dholmes at openjdk.org  Sun May 19 22:25:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 19 May 2024 22:25:01 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
Message-ID: <COUkpP9TlXdkKVhCc-4F45scx0JjYlz5JirmEtIh5jw=.9be0c848-183c-4bcf-9f01-3a028968cb63@github.com>

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong thread state

I don't understand the additional changes because they read the current thread's name, whereas this issue is about reading an arbitrary thread's name when the current thread happens to be in the wrong state. ???

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

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2119378363

From dholmes at openjdk.org  Mon May 20 01:50:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 May 2024 01:50:03 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>
Message-ID: <Ajo-HpworMy3C3fHjwSr-sz-eI2udigAACE5WAxYwzQ=.9292026b-e40c-48cb-ad12-9ffbab39a604@github.com>

On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple of minor typos in comments.

> Note we can't check if the current thread owns a lock without grabbing dbgRawMonitor. In fact the main purpose of dbgRawMonitor is to allow the current thread to check if it owns the monitor.

That smells fishy to me. A thread can always safely check if it owns something because it can't race with itself and get a wrong answer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2119525715

From cjplummer at openjdk.org  Mon May 20 03:26:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 20 May 2024 03:26:07 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <Ajo-HpworMy3C3fHjwSr-sz-eI2udigAACE5WAxYwzQ=.9292026b-e40c-48cb-ad12-9ffbab39a604@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>
 <Ajo-HpworMy3C3fHjwSr-sz-eI2udigAACE5WAxYwzQ=.9292026b-e40c-48cb-ad12-9ffbab39a604@github.com>
Message-ID: <ivJDeS82VOryrc7sksYikKX_uKGcOToFXMGQZx2iHYk=.a67b1d80-dc81-4d06-8e39-02250ba70632@github.com>

On Mon, 20 May 2024 01:47:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That smells fishy to me. A thread can always safely check if it owns something because it can't race with itself and get a wrong answer.

Unfortunately checking ownership means comparing jobjects, which you can't safely do if you are comparing to a jobject that could be freed at any moment (I'm referring the JNI ref being freed, not the object being GC'd). I ran into asserts in JNI IsSameObject() due to this happening. Basically the local ref became invalid between the time it was fetched from the DebugRawMonitor and when is was used by IsSameObject().

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2119592870

From dholmes at openjdk.org  Mon May 20 03:53:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 May 2024 03:53:03 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
Message-ID: <tLV394cjTjTCabL8p2C9D_GYCOrbi3B48g3saWCu1wc=.d636a597-be19-4bfa-92ba-2b7a674bff84@github.com>

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong thread state

Okay now I get it. Even once the function is made truly safe, we are always calling it from an unsafe state and so will get the default `Thread::name` response. So now, after any transition to the VM the name is read again to get a good value. This seems a good enhancement though I have to wonder if the apparent changing of the thread name in the tracing might cause problems. The tracing really needs to include a unique thread identifier.

Thanks

src/hotspot/share/prims/jvmtiEventController.cpp line 961:

> 959: JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent event_type, bool added) {
> 960:   int *count_addr;
> 961: 

Nit: this file doesn't need to be touched.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19275#pullrequestreview-2065287663
PR Review Comment: https://git.openjdk.org/jdk/pull/19275#discussion_r1606209679

From dholmes at openjdk.org  Mon May 20 04:28:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 May 2024 04:28:06 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <ivJDeS82VOryrc7sksYikKX_uKGcOToFXMGQZx2iHYk=.a67b1d80-dc81-4d06-8e39-02250ba70632@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>
 <Ajo-HpworMy3C3fHjwSr-sz-eI2udigAACE5WAxYwzQ=.9292026b-e40c-48cb-ad12-9ffbab39a604@github.com>
 <ivJDeS82VOryrc7sksYikKX_uKGcOToFXMGQZx2iHYk=.a67b1d80-dc81-4d06-8e39-02250ba70632@github.com>
Message-ID: <Bvk8_ufN1YT6NzL8fsH3fBlriZvhz7HEspbjDNE0quc=.456299cf-a9fd-4ac0-8481-5299e8d19830@github.com>

On Mon, 20 May 2024 03:23:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Unfortunately checking ownership means comparing jobjects, which you can't safely do if you are comparing to a jobject that could be freed at any moment

Okay but how does this `dbgRawMonitor` lock prevent the GC from clearing a jobject?

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2119642215

From cjplummer at openjdk.org  Mon May 20 04:39:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 20 May 2024 04:39:07 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v8]
In-Reply-To: <Bvk8_ufN1YT6NzL8fsH3fBlriZvhz7HEspbjDNE0quc=.456299cf-a9fd-4ac0-8481-5299e8d19830@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <C-ZDf0zDVuXcBdWJ4X2_3KP6CHxJ-C9v9cpsiK7ZtWo=.9005f07b-084c-4a73-b838-4fead5840cc4@github.com>
 <Ajo-HpworMy3C3fHjwSr-sz-eI2udigAACE5WAxYwzQ=.9292026b-e40c-48cb-ad12-9ffbab39a604@github.com>
 <ivJDeS82VOryrc7sksYikKX_uKGcOToFXMGQZx2iHYk=.a67b1d80-dc81-4d06-8e39-02250ba70632@github.com>
 <Bvk8_ufN1YT6NzL8fsH3fBlriZvhz7HEspbjDNE0quc=.456299cf-a9fd-4ac0-8481-5299e8d19830@github.com>
Message-ID: <ySXS3lfxDKNHE3SEEp9-fD8eRUvIB6xr8Kw1F6xhEdQ=.aeef1306-30c6-48b1-acb1-d22b98d97bb8@github.com>

On Mon, 20 May 2024 04:25:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay but how does this `dbgRawMonitor` lock prevent the GC from clearing a jobject?

The JNI ref. It's actually a global ref (I said local ref earlier). As long as any setters of DebugRawMonitor::ownerThread (setting the thread or clearing it) grab dbgRawMonitor first, and the current thread accessing ownerThread does the same, then you know that whatever ownerThread points to is either NULL, the current thread, or some other thread that is still alive and is actually holding the monitor that the DebugRawMonitor is encapsulating. As long as the current thread continues to hold dbgRawMonitor, no other thread will be able to change ownerThread. This means that if some other thread currently owns the monitor that the DebugRawMonitor is encapsulating, then it will first block on dbgRawMonitor before trying to release it and clear ownerThread.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2119650743

From alanb at openjdk.org  Mon May 20 06:02:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 06:02:01 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
Message-ID: <G0D-9XxW58WNiGYygJFI5ijvySOYzeWO4-_okKB6pAo=.20db6085-e912-453a-9543-d711deabc26e@github.com>

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong thread state

Are there tests that run with TraceJVMTI so that this option is tested?

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

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2119724541

From alanb at openjdk.org  Mon May 20 08:12:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 08:12:02 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
 <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
Message-ID: <6zDrA0b4meB2PNnopX2wSHm3HFBCPScHj4PjBInaF5M=.d8a1e42b-f975-41c0-960c-85e53debb57a@github.com>

On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
>>> 
>>> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
>>> 
>>> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.
>> 
>> If jconsole is passing null, why is it triggering this exception?
>
>> If jconsole is passing null, why is it triggering this exception?
> 
> JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.
> 
> (JConsole running on jdk-23 can connect to jdk-23 fine.)
> (Also just to note, a jdk-23 JConsole can connect to an older JDK and show the MBean tab OK.)

@kevinjwalls I assume the RN for the removal of the subject delegation feature will need to be adjusted once this current PR is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2119907523

From kevinw at openjdk.org  Mon May 20 10:35:02 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 May 2024 10:35:02 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <GxBSkCFb_MWeYQTXCE_Qlu9x2qeBKwMOUVTCqbsoYgI=.604e7cc4-d8a2-41ac-a59e-a600f638c89d@github.com>

On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

Looks good - with the asterisk * prefix question from the other comment.
I looked to check and yes the since 10 is correct.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19263#pullrequestreview-2065901430

From dfuchs at openjdk.org  Mon May 20 13:23:02 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 May 2024 13:23:02 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java
In-Reply-To: <F4xM2SA2h5Suu3ZFTWdJH6gh5MNLlRc79EHAdvcKm1w=.2a80b20d-6bdd-44ec-9d18-f2be83de9e78@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <i4qyeHY6f2zbEnY4IE_a2ZMbaBvpITvVD9pXoGTerDI=.90c09f8c-4968-43e7-b7a8-e06ded699ef7@github.com>
 <F4xM2SA2h5Suu3ZFTWdJH6gh5MNLlRc79EHAdvcKm1w=.2a80b20d-6bdd-44ec-9d18-f2be83de9e78@github.com>
Message-ID: <FSuj8OoOlSoZNszGNpVRxrYHx7cFUUVmmbB0eo2O6zY=.daf8a1d5-7801-4cdf-822c-4f48a7c6b564@github.com>

On Sun, 19 May 2024 19:05:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 26:
>> 
>>> 24:  */
>>> 25: 
>>> 26: /**
>> 
>> I assume you'll need to prepend each line with `*` too, which has the side effect of making it appear that every line is changed but I think we just need to get over that.
>
> Doing that makes git think it's a new file, rather than a rename.
> I was doing this in [a26ee08](https://github.com/openjdk/jdk/commit/a26ee085b5184d62a879f88f6cca6780e0e4e472) and removed it

LGTM - there are further potential improvements that could be made in this file - like replacing `<code></code>` with `{@code }` and `<pre></pre>` with `{@snippet }` but I guess that can wait until someone has the inclination and bandwidth to do it...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1606772388

From kevinw at openjdk.org  Mon May 20 14:22:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 May 2024 14:22:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
 <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
Message-ID: <n5W4f3SzxVpghMXf3YRM1vaS8-jaHcbcMMTCNd9vR_g=.d43817ac-eca5-45e8-adb5-a180e0040845@github.com>

On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
>>> 
>>> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
>>> 
>>> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.
>> 
>> If jconsole is passing null, why is it triggering this exception?
>
>> If jconsole is passing null, why is it triggering this exception?
> 
> JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.
> 
> (JConsole running on jdk-23 can connect to jdk-23 fine.)
> (Also just to note, a jdk-23 JConsole can connect to an older JDK and show the MBean tab OK.)

> @kevinjwalls I assume the RN for the removal of the subject delegation feature will need to be adjusted once this current PR is integrated.

When this fix goes in, there will be a window of builds between jdk 23+18 to jdk-23+build_with_this_fix, where older JMX clients using addNotificationListener() will see an exception.  I wasn't going to highlight this in the RN, I thought JDK-8332303 looks quite discoverable already.  If the RN is the place to discuss temporary and now-fixed issues with selection of earlier builds before release, I could add something there.

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2120560237

From lmesnik at openjdk.org  Mon May 20 17:13:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 20 May 2024 17:13:01 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
Message-ID: <J03zeOvKDQEfLByYp8coAI_6yi_tsbbef2IVJGJpy1Q=.fa20b8cd-d146-45b6-a34b-4df919eef186@github.com>

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong thread state

There are no tests currently executed with TraceJVMTI.
I am thinking about adding execution of the svc testing. However I've got another failure that should resolved before
https://bugs.openjdk.org/browse/JDK-8332536
It is not related to the current issue.
Probably, it makes sense to add some basic logging testing with verification of log content also.

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

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2120856531

From nbenalla at openjdk.org  Mon May 20 18:10:18 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 18:10:18 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v2]
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <oGgokNn3aCMc8-KusTJ2sTllAJXlm-L8S81Nt9ysNGs=.636df131-87bf-4fcb-a936-cb5957a6e98b@github.com>

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  append each line with " *"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19263/files
  - new: https://git.openjdk.org/jdk/pull/19263/files/52d3d182..e2471645

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

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

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

From nbenalla at openjdk.org  Mon May 20 18:15:17 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 18:15:17 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <FSuj8OoOlSoZNszGNpVRxrYHx7cFUUVmmbB0eo2O6zY=.daf8a1d5-7801-4cdf-822c-4f48a7c6b564@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <i4qyeHY6f2zbEnY4IE_a2ZMbaBvpITvVD9pXoGTerDI=.90c09f8c-4968-43e7-b7a8-e06ded699ef7@github.com>
 <F4xM2SA2h5Suu3ZFTWdJH6gh5MNLlRc79EHAdvcKm1w=.2a80b20d-6bdd-44ec-9d18-f2be83de9e78@github.com>
 <FSuj8OoOlSoZNszGNpVRxrYHx7cFUUVmmbB0eo2O6zY=.daf8a1d5-7801-4cdf-822c-4f48a7c6b564@github.com>
Message-ID: <4ssnCnWfoNweZzRT3W2sfYKq1ojEZLWMX15dyyUTBVY=.b42fb343-2d21-4d32-9a80-4f6fb82aa192@github.com>

On Mon, 20 May 2024 13:19:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Doing that makes git think it's a new file, rather than a rename.
>> I was doing this in [a26ee08](https://github.com/openjdk/jdk/commit/a26ee085b5184d62a879f88f6cca6780e0e4e472) and removed it
>
> LGTM - there are further potential improvements that could be made in this file - like replacing `<code></code>` with `{@code }` and `<pre></pre>` with `{@snippet }` but I guess that can wait until someone has the inclination and bandwidth to do it...

Fixed, found how to "lazily" append to the lines I want so adding the " *" wasn't an issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607108275

From nbenalla at openjdk.org  Mon May 20 18:15:16 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 18:15:16 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Remove tabs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19263/files
  - new: https://git.openjdk.org/jdk/pull/19263/files/e2471645..232a533a

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

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

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

From prr at openjdk.org  Mon May 20 18:50:06 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
Message-ID: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>

On Mon, 13 May 2024 10:49:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> make/conf/module-loader-map.conf line 105:
> 
>> 103:     java.smartcardio \
>> 104:     jdk.accessibility \
>> 105:     jdk.attach \
> 
> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

> src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     @SuppressWarnings({"removal", "restricted"})
> 
> There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

Sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136237
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136808

From prr at openjdk.org  Mon May 20 18:50:04 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Have you looked into / thought about how this will work for jpackaged apps ?
I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options.
Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

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

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2066794950

From alanb at openjdk.org  Mon May 20 18:54:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 18:54:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
 <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
Message-ID: <nFi5XR2qKdd2WstJE4gWSS3UGpk7uOvK4Gn7x0wArIs=.8e22fd11-0e2d-4328-81eb-81bf129ea65d@github.com>

On Mon, 20 May 2024 18:39:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/conf/module-loader-map.conf line 105:
>> 
>>> 103:     java.smartcardio \
>>> 104:     jdk.accessibility \
>>> 105:     jdk.attach \
>> 
>> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.
>
> Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
> ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

Yes, this was added via JDK-8327218. The changes in this PR are just trimming down the list to only the modules that have native code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607147983

From rriggs at openjdk.org  Mon May 20 18:56:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 20 May 2024 18:56:07 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
Message-ID: <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>

On Mon, 20 May 2024 18:15:16 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
>> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
>> The conversion was done in-place, only renaming it in git.
>> 
>> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
>> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tabs

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 121:

> 119:      *
> 120:      * @since 10
> 121:      */

Please fix the indentation of the "*" for the this comment on CREDENTIALS_FILTER_PATTERN so it looks consistent.

src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 325:

> 323:  *    @since 1.5
> 324:  *
> 325:  **/

Extra *  `*/` is sufficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607149187
PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607146703

From nbenalla at openjdk.org  Mon May 20 19:00:34 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 19:00:34 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>
Message-ID: <ocGe8TPOQasW-vV9zNEk-LHLJuAY2i5HmitHCXj1R-c=.d420e81a-ec1e-42f8-a423-1c5157432ff0@github.com>

On Mon, 20 May 2024 18:50:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove tabs
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 325:
> 
>> 323:  *    @since 1.5
>> 324:  *
>> 325:  **/
> 
> Extra *  `*/` is sufficient.

Fixed in [393bf3a](https://github.com/openjdk/jdk/pull/19263/commits/393bf3a36e3fb0811f89ef21cbdbb4a32a7a3e21), thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607154339

From nbenalla at openjdk.org  Mon May 20 19:00:33 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 19:00:33 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v4]
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <RbbJM_vUrhmaNka3iL5NHCRyIgL2iDyTOo2cTuHkavU=.2341423c-6de1-401e-a957-1b59796699a1@github.com>

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  suggestions from roger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19263/files
  - new: https://git.openjdk.org/jdk/pull/19263/files/232a533a..393bf3a3

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

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

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

From nbenalla at openjdk.org  Mon May 20 19:04:02 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 19:04:02 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>
Message-ID: <GWMe0O1J4ezqxIUNDynzvSBvp3-Vk7FZSr_w9d7STqI=.2ba12b74-d788-4693-86c8-5b1a7b0d806b@github.com>

On Mon, 20 May 2024 18:52:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove tabs
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 121:
> 
>> 119:      *
>> 120:      * @since 10
>> 121:      */
> 
> Please fix the indentation of the "*" for the this comment on CREDENTIALS_FILTER_PATTERN so it looks consistent.

Fixed to be consistent, but the rest of the comment is still indented wrong.

/**
* Name of the attribute that specifies ...
* ....

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607157750

From rriggs at openjdk.org  Mon May 20 20:37:03 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 20 May 2024 20:37:03 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v3]
In-Reply-To: <GWMe0O1J4ezqxIUNDynzvSBvp3-Vk7FZSr_w9d7STqI=.2ba12b74-d788-4693-86c8-5b1a7b0d806b@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 <Wbr6NpGRv5akehMiWgn6TV3k9ecWsQQPtuZZAU1xh5g=.5e3aa211-a4d6-40dc-ab51-a37fac2c35e5@github.com>
 <GWMe0O1J4ezqxIUNDynzvSBvp3-Vk7FZSr_w9d7STqI=.2ba12b74-d788-4693-86c8-5b1a7b0d806b@github.com>
Message-ID: <BDkFCsqMZov2mWNEBt1qY5uujl32h8xvzD0FxU46iMg=.9e03951c-962e-48d3-a56d-a9933522131b@github.com>

On Mon, 20 May 2024 19:01:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 121:
>> 
>>> 119:      *
>>> 120:      * @since 10
>>> 121:      */
>> 
>> Please fix the indentation of the "*" for the this comment on CREDENTIALS_FILTER_PATTERN so it looks consistent.
>
> Fixed to be consistent, but the rest of the comment is still indented wrong.
> 
> /**
> * Name of the attribute that specifies ...
> * ....

(I would have gone the other way and corrected the preceding indentation to the standard).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1607248724

From nbenalla at openjdk.org  Mon May 20 20:55:16 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 May 2024 20:55:16 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v5]
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <m8Kt04mSOvAGYDjWtnkRakCynsl6qcI-Myi7YmotoSI=.8a7cd5f3-e3b1-4bc5-832b-236b36c77ea1@github.com>

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19263/files
  - new: https://git.openjdk.org/jdk/pull/19263/files/393bf3a3..82536dd9

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

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

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

From sspitsyn at openjdk.org  Mon May 20 23:47:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 May 2024 23:47:01 GMT
Subject: RFR: 8331683: Clean up GetCarrierThread
In-Reply-To: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
References: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
Message-ID: <fx-zvFiWZP6HHAk_KoY6PGTXuisTnPpiwmSFwDN3nss=.211511cf-a375-4c89-b7ae-4ea41801b72c@github.com>

On Sat, 18 May 2024 00:47:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JVMTI GetCarrierThread extension function was introduced by loom for testing.
> It's used by several tests in hotspot/jtreg/serviceability.
> 
> Testings: tier1..tier6

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19289#pullrequestreview-2067222107

From cjplummer at openjdk.org  Tue May 21 06:12:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 May 2024 06:12:07 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v12]
In-Reply-To: <jndqQQhaWY-AdOhgwSqkFxJeAEulSap-QrT9OiB4GQc=.cfa532f4-6894-4946-b687-aafd82268dbf@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <jndqQQhaWY-AdOhgwSqkFxJeAEulSap-QrT9OiB4GQc=.cfa532f4-6894-4946-b687-aafd82268dbf@github.com>
Message-ID: <27qGzorWxtdq6HLmIMPLHZ6_qRbOZo2DvA7pewZfNKA=.3f11daeb-1645-466e-b4bb-56aab62021b2@github.com>

On Sat, 18 May 2024 09:07:18 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   restore

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java line 90:

> 88:         // before dumping the string table. That means the heap should contain no
> 89:         // humongous regions.
> 90:         dumpOutput.shouldNotMatch("gc,region,cds. G1HeapRegion 0x[0-9a-f]* HUM");

Just a minor nit. I noticed a pre-existing typo on line 87 above. It says "kelp" instead of "kept". Can you fix it?

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

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2067620880
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1607694956

From alanb at openjdk.org  Tue May 21 07:23:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 May 2024 07:23:07 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
Message-ID: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>

On Mon, 20 May 2024 18:47:35 GMT, Phil Race <prr at openjdk.org> wrote:

> Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2121927727

From mcimadamore at openjdk.org  Tue May 21 08:47:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 May 2024 08:47:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
Message-ID: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>

On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.
> 
> I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application. The same is true for creating JDK image jlink (which we use in the jextract build) - although, in that case the end user also has the possibility to pass options on the command line.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2122095444

From asemenyuk at openjdk.org  Tue May 21 15:57:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 15:57:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <Z4v5RDWq81-UKvhkRVYPggJwn6H10GkMrmtTXhfmfkU=.5644db12-51a7-4b98-8923-04e5912d15cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

`jdk.jpackage` changes look good

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2122942586

From prr at openjdk.org  Tue May 21 16:45:06 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 May 2024 16:45:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <2sHuToXAXHYrqtE31r7-wDvJ3JM0nQYujuLFAtqWQQI=.3c61631b-ecb1-4073-9b5f-6a379ab614cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

client parts look fine.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2069134455

From duke at openjdk.org  Tue May 21 16:53:02 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 21 May 2024 16:53:02 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <5jtxG7mdbPDU7_iroUJP04Kut6e7o1_5XF2Ht_L9ciE=.67b51646-bcab-4fe8-a192-9d8e63a3e31b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
 <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>
 <5jtxG7mdbPDU7_iroUJP04Kut6e7o1_5XF2Ht_L9ciE=.67b51646-bcab-4fe8-a192-9d8e63a3e31b@github.com>
Message-ID: <QWf-26XEwYFr65ixVSMHapdXKMfAaIWrqTiE6d6JnRI=.85503dfc-2ee3-461c-89a5-d02998dd41a0@github.com>

On Sun, 12 May 2024 18:38:34 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> In these cases, is it not a requirement that jcmd is run as root? So even if the target process is run with elevated privileges, attaching would always work. Or is there some way to attach from host to container with a non-root user that I'm missing?

Or could it work in case the container is also run as a non-`root` user?

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2123042958

From asemenyuk at openjdk.org  Tue May 21 16:59:04 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 16:59:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
 <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
Message-ID: <xZ1AEmH_qkn4fErnw7SyycG07-_XN0Sr0OdvCPGEaQQ=.358a6210-b5a3-4b3e-a15f-bd89aa212f42@github.com>

On Tue, 21 May 2024 08:44:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application.

It would be good to document how jpackage users packaging apps with native access will be affected by this change. Primarily that they need to pass `--illegal-native-access` parameter to affected jpackage app launchers.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2123054154

From duke at openjdk.org  Tue May 21 17:10:15 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 21 May 2024 17:10:15 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
Message-ID: <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>

> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused `SELF_PID_NS`
 - Rewrite in line with suggestion from Larry Cable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19055/files
  - new: https://git.openjdk.org/jdk/pull/19055/files/d3e26a0c..c57b4598

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

  Stats: 110 lines in 1 file changed: 59 ins; 14 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/19055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055

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

From duke at openjdk.org  Tue May 21 17:10:16 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 21 May 2024 17:10:16 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <kqrjab_LaWvUIJQKoQq6gTrNGZ3U2m5QfIOWCnyD-gA=.af3e1b00-5efe-4ac6-ae47-a1ebb51f6283@github.com>
 <HG0ISo9_LmL8tWWS80cTCTxWJ9_lTV8CKDLsbRltgfY=.2140e5a5-d739-4a5e-af02-12830e576b7f@github.com>
Message-ID: <GpOKmLz14zd8pQuEdiH5Ag-JDdAXyrBIvkLcLD43KXw=.cb4c352d-27cf-4bf0-ac16-68bb15b70d41@github.com>

On Mon, 6 May 2024 18:31:06 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked attach logic
>
> On 5/6/24 10:35 AM, Sebastian L?vdahl wrote:
>>
>> I pushed an updated attempt at this now with d3e26a0 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d3e26a0c444e06ba9757fd528d72d83f56cd098b__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svPHZrq9ZQ$>. 
>> Local testing and |make test 
>> TEST="jtreg:test/hotspot/jtreg/containers"| + |make test 
>> TEST="jtreg:test/hotspot/jtreg/serviceability"| indicate that all the 
>> known use-cases work.
>>
>> Still eager to see what you come up with @larry-cable 
>> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNMPdGFLg$>. 
>> |createAttachFile| could still be improved for example. And I would 
>> also be interested in looking into writing some test for the elevated 
>> privileges case.
>>
>> ?
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2096564990__;Iw!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svNUwHWtZA$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGOTAXCKY2TO2OBDDZA65N5AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGU3DIOJZGA__;!!ACWV5N9M2RV99hQ!M_KzQgiC8WkHTfJnvTw6zsw7l0RACDgJU3ShDs0R1dAWE_IxEinuX1_Uqom0UPt96Bl6iEqHc-yUUmz5svO2ymONGw$>.
>> You are receiving this because you were mentioned.Message ID: 
>> ***@***.***>
>>
> 
> 
>  ?/*
> diff --git 
> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> index 81d4fd259ed..c148dbd61b7 100644
> --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
> @@ -34,6 +34,7 @@
>  ?import java.nio.file.Path;
>  ?import java.nio.file.Paths;
>  ?import java.nio.file.Files;
> +import java.util.Optional;
> 
>  ?import static java.nio.charset.StandardCharsets.UTF_8;
> 
> @@ -46,8 +47,28 @@ public class VirtualMachineImpl extends 
> HotSpotVirtualMachine {
>  ???? // location is the same for all processes, otherwise the tools
>  ???? // will not be able to find all Hotspot processes.
>  ???? // Any changes to this needs to be synchronized with HotSpot.
> -??? private static final String tmpdir = "/tmp";
> +??? private static final Path TMPD...

I tested your patch @larry-cable, and, as far as I can tell, everything works. I ran through all the cases in https://github.com/openjdk/jdk/pull/19055#issuecomment-2090136676 once more to verify this. Thanks! Feel free to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2123072183

From cjplummer at openjdk.org  Tue May 21 19:09:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 May 2024 19:09:04 GMT
Subject: RFR: 8331683: Clean up GetCarrierThread
In-Reply-To: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
References: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
Message-ID: <Ikzc-jSOIaXaCv3D2i9_boM52ML7qBl9PCD1TK92_BQ=.1e17950b-6845-4082-993b-c60fb1b2e198@github.com>

On Sat, 18 May 2024 00:47:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JVMTI GetCarrierThread extension function was introduced by loom for testing.
> It's used by several tests in hotspot/jtreg/serviceability.
> 
> Testings: tier1..tier6

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19289#pullrequestreview-2069434194

From lmesnik at openjdk.org  Tue May 21 20:02:26 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 21 May 2024 20:02:26 GMT
Subject: RFR: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization
Message-ID: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>

The BindServer starts several threads and opens streams.

It registered them for cleanup using "Finalizer" from nsk.share.framework. Currently, it cleanup resources during shutdown hook.

This fix changes BindServer to explicitly close streams and finish threads after test is completed. The exceptions are just printed like it was done previously. I haven't caught any exception during in close method during testing.

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

Commit messages:
 - 8332631: Update nsk.share.jpda.BindServer to don't use finalization

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

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

From duke at openjdk.org  Tue May 21 21:09:02 2024
From: duke at openjdk.org (Larry Cable)
Date: Tue, 21 May 2024 21:09:02 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
Message-ID: <CzLNv1cs9afj06CoK8CpKIQ-hGEN7LYtroLkzSLlxu8=.33ea4706-f5be-447e-916b-2a9ebfc5791b@github.com>

On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

Hi Sebastian!

On 5/21/24 9:50 AM, Sebastian L?vdahl wrote:
>
>     In these cases, is it not a requirement that jcmd is run as root?
>     So even if the target process is run with elevated privileges,
>     attaching would always work.
>

the constraint (as I understand it) is based upon the filesystem access 
to /proc/<attachee>/root/tmp, where the createAttachFile fails... if the 
"attacher" (jcmd) has access, if it has the
appropriate +og r/w access then it will be successful.

the "root" requirement comes from the default behavior of the container 
mgmt (docker) running containers as 'root'.

if you employ the --user option to 'force' the container to adopt a 
non-root identity jcmd will succeed if issued from the same 
user&group... because it has r/w access to the /proc/<attachee>/root/tmp

note: if the container is in a distinct uid ns (from the attacher) I 
think the current checks performed by 
*os::Posix::matches_effective_uid_and_gid_or_root* will complete since 
the comparison is based on the uid values returned by the O.S 
(independent of the fact that the uid's may exist in distinct uid ns'es!)

>     Or is there some way to attach from host to container with a
>     non-root user that I'm missing?
>
> Or could it work in case the container is also run as a non-|root| user?
>

the use case I was addressing with my proposal is when the jcmd 
"container" (as a sidecar) is in the same pid ns as the target container 
but in a different mnt ns (I believe this is the regression use case) in 
that case falling back
to /tmp will not work and since the attacher and the attachee do not 
share a fs...

if the target JVM has elevated privs a (sidecar) attacher cannot use the 
target's /proc/<attachee>/root/... hence my experiment to recurse "up" 
the attachee's pid ns to look for a an un-privileged ancestor, which does
share the same mnt ns as the attachee, so the attacher can use the 
/proc/<ancestor>/root/tmp to attach to the target... all things being 
equal...

Rgds

- Larry

> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2123042958__;Iw!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbKzJlBhjQ$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67XPE34N46VDFUEMSHDZDN3NHAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGA2DEOJVHA__;!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbLIEsaUnQ$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------XQdcZo9hO6wbcp2fGsjP1B9A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    Hi Sebastian!<br>
    <br>
    <div class="moz-cite-prefix">On 5/21/24 9:50 AM, Sebastian L?vdahl
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <blockquote>
        <p dir="auto">In these cases, is it not a requirement that jcmd
          is run as root? So even if the target process is run with
          elevated privileges, attaching would always work. </p>
      </blockquote>
    </blockquote>
    <br>
    the constraint (as I understand it) is based upon the filesystem
    access to /proc/&lt;attachee&gt;/root/tmp, where the
    createAttachFile fails... if the &quot;attacher&quot; (jcmd) has access, if it
    has the<br>
    appropriate +og r/w access then it will be successful.<br>
    <br>
    the &quot;root&quot; requirement comes from the default behavior of the
    container mgmt (docker) running containers as 'root'.<br>
    <br>
    if you employ the --user option to 'force' the container to adopt a
    non-root identity jcmd will succeed if issued from the same
    user&amp;group... because it has r/w access to the
    /proc/&lt;attachee&gt;/root/tmp<br>
    <br>
    note: if the container is in a distinct uid ns (from the attacher) I
    think the current checks performed by <font face="Courier New, Courier, monospace"><b>os::Posix::matches_effective_uid_and_gid_or_root</b></font>
    will complete since the comparison is based on the uid values
    returned by the O.S (independent of the fact that the uid's may
    exist in distinct uid ns'es!)<br>
    <br>
    <blockquote type="cite" ***@***.***">
      <blockquote>
        <p dir="auto">Or is there some way to attach from host to
          container with a non-root user that I'm missing?</p>
      </blockquote>
      <p dir="auto">Or could it work in case the container is also run
        as a non-<code class="notranslate">root</code> user?</p>
    </blockquote>
    <br>
    the use case I was addressing with my proposal is when the jcmd
    &quot;container&quot; (as a sidecar) is in the same pid ns as the target
    container but in a different mnt ns (I believe this is the
    regression use case) in that case falling back<br>
    to /tmp will not work and since the attacher and the attachee do not
    share a fs...<br>
    <br>
    if the target JVM has elevated privs a (sidecar) attacher cannot use
    the target's /proc/&lt;attachee&gt;/root/... hence my experiment to
    recurse &quot;up&quot; the attachee's pid ns to look for a an un-privileged
    ancestor, which does<br>
    share the same mnt ns as the attachee, so the attacher can use the
    /proc/&lt;ancestor&gt;/root/tmp to attach to the target... all
    things being equal...<br>
    <br>
    Rgds<br>
    <br>
    - Larry<br>
    <br>
    <blockquote type="cite" ***@***.***">
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2123042958__;Iw!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbKzJlBhjQ$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67XPE34N46VDFUEMSHDZDN3NHAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGA2DEOJVHA__;!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbLIEsaUnQ$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67Q4FA2GDVB3NAFU5I3ZDN3NHA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6RMII4.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/19055/c2123042958</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2123042958",
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2123042958",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------XQdcZo9hO6wbcp2fGsjP1B9A--

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2123442646

From lmesnik at openjdk.org  Tue May 21 21:54:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 21 May 2024 21:54:22 GMT
Subject: RFR: 8332641: Update nsk.share.jpda.Jdb to don't use finalization
Message-ID: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>

The nsk.share.jdb.Jdb has finalize() nethods that close jdb connection and output streams.

The fix renames the method to close() and calls it explicitly after the test finishes. I verified that close() called for each nsk share jdb test.

The jdb is also LocalProcess with it's own cleanup(). This part still remains the same so far.

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

Commit messages:
 - 8332641: Update nsk.share.jpda.Jdb to don't use finalization

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

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

From ihse at openjdk.org  Wed May 22 08:59:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 08:59:03 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <y3fQHNtP45EGmJmrVWNT1SMBgNP6GgYvHGM4v0Hz2h0=.ba07a68b-ea4b-4620-9e0f-70a413d0b002@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Build changes look good. Thanks for trimming down NATIVE_ACCESS_MODULES.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2070573791

From duke at openjdk.org  Wed May 22 09:40:04 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 22 May 2024 09:40:04 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <CzLNv1cs9afj06CoK8CpKIQ-hGEN7LYtroLkzSLlxu8=.33ea4706-f5be-447e-916b-2a9ebfc5791b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
 <CzLNv1cs9afj06CoK8CpKIQ-hGEN7LYtroLkzSLlxu8=.33ea4706-f5be-447e-916b-2a9ebfc5791b@github.com>
Message-ID: <OrCpsazaRBg5FMAUQNbGq55mWwW7DyjaL0N89ZB8lwc=.69862faf-2074-44e4-a145-344c2f00e280@github.com>

On Tue, 21 May 2024 21:06:22 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unused `SELF_PID_NS`
>>  - Rewrite in line with suggestion from Larry Cable
>
> Hi Sebastian!
> 
> On 5/21/24 9:50 AM, Sebastian L?vdahl wrote:
>>
>>     In these cases, is it not a requirement that jcmd is run as root?
>>     So even if the target process is run with elevated privileges,
>>     attaching would always work.
>>
> 
> the constraint (as I understand it) is based upon the filesystem access 
> to /proc/<attachee>/root/tmp, where the createAttachFile fails... if the 
> "attacher" (jcmd) has access, if it has the
> appropriate +og r/w access then it will be successful.
> 
> the "root" requirement comes from the default behavior of the container 
> mgmt (docker) running containers as 'root'.
> 
> if you employ the --user option to 'force' the container to adopt a 
> non-root identity jcmd will succeed if issued from the same 
> user&group... because it has r/w access to the /proc/<attachee>/root/tmp
> 
> note: if the container is in a distinct uid ns (from the attacher) I 
> think the current checks performed by 
> *os::Posix::matches_effective_uid_and_gid_or_root* will complete since 
> the comparison is based on the uid values returned by the O.S 
> (independent of the fact that the uid's may exist in distinct uid ns'es!)
> 
>>     Or is there some way to attach from host to container with a
>>     non-root user that I'm missing?
>>
>> Or could it work in case the container is also run as a non-|root| user?
>>
> 
> the use case I was addressing with my proposal is when the jcmd 
> "container" (as a sidecar) is in the same pid ns as the target container 
> but in a different mnt ns (I believe this is the regression use case) in 
> that case falling back
> to /tmp will not work and since the attacher and the attachee do not 
> share a fs...
> 
> if the target JVM has elevated privs a (sidecar) attacher cannot use the 
> target's /proc/<attachee>/root/... hence my experiment to recurse "up" 
> the attachee's pid ns to look for a an un-privileged ancestor, which does
> share the same mnt ns as the attachee, so the attacher can use the 
> /proc/<ancestor>/root/tmp to attach to the target... all things being 
> equal...
> 
> Rgds
> 
> - Larry
> 
>> ?
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2123042958__;Iw!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbKzJlBhjQ$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67XPE34N46VDFUEMSHDZDN3NHAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGA2DEOJVHA__;!!AC...

Thanks for the explanation @larry-cable, that makes sense. By chance, did you already test the Docker `--user` case with the suggested patch? I don't have access to an environment with rootless Docker at hand, but I may be able to set it up in a VM if you didn't already test it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2124324590

From duke at openjdk.org  Wed May 22 11:23:03 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 22 May 2024 11:23:03 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
Message-ID: <hu79O47p3WJxgCIRvQe24GSC0-aVprVevj3e17pKIa8=.dc8a889e-eb5f-435a-988c-a7580ba52318@github.com>

On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

I set up rootless Docker in a VM by following https://docs.docker.com/engine/security/rootless.


slovdahl at slovdahl-virtual-machine:~$ systemctl status --user docker.service 
? docker.service - Docker Application Container Engine (Rootless)
     Loaded: loaded (/home/slovdahl/.config/systemd/user/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-05-22 13:55:06 EEST; 5min ago
       Docs: https://docs.docker.com/go/rootless/
   Main PID: 3314 (rootlesskit)
      Tasks: 58
     Memory: 596.4M
        CPU: 16.821s
     CGroup: /user.slice/user-1000.slice/user at 1000.service/app.slice/docker.service
             ??3314 rootlesskit --state-dir=/run/user/1000/dockerd-rootless --net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin --copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dockerd>
             ??3325 /proc/self/exe --state-dir=/run/user/1000/dockerd-rootless --net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin --copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dock>
             ??3343 slirp4netns --mtu 65520 -r 3 --disable-host-loopback --enable-sandbox --enable-seccomp 3325 tap0
             ??3350 dockerd
             ??3373 containerd --config /run/user/1000/docker/containerd/containerd.toml
             ??4116 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 3a84c6c9f7b8ee6220b8953b65ff56639dd51335999cb37580292f4944ee0e65 -address /run/user/1000/docker/containerd/containerd.sock


Started a container running as my user:

slovdahl at slovdahl-virtual-machine:~$ docker run --name reproducer --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81


Using the Ubuntu OpenJDK 17 package:

slovdahl at slovdahl-virtual-machine:~$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)

slovdahl at slovdahl-virtual-machine:~$ jcmd
4139 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
5965 jdk.jcmd/sun.tools.jcmd.JCmd

slovdahl at slovdahl-virtual-machine:~$ jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using mainline JDK without the changes in this PR:

slovdahl at slovdahl-virtual-machine:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using JDK built from this PR:

slovdahl at slovdahl-virtual-machine:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using a sidecar container mounted into the same PID namespace with Eclipse Temurin 17:

slovdahl at slovdahl-virtual-machine:~$ docker run --interactive --tty --rm --pid=container:reproducer eclipse-temurin:17.0.11_9-jdk-jammy /bin/bash
root at b746aeae40d2:/# jcmd
44 jdk.jcmd/sun.tools.jcmd.JCmd
root at b746aeae40d2:/# jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using a sidecar container mounted into the same PID namespace with mainline JDK (expected to fail):

slovdahl at slovdahl-virtual-machine:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
root at 7b0c9dc87175:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
234 jdk.jcmd/sun.tools.jcmd.JCmd
root at 7b0c9dc87175:/# /jdk/bin/jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:99)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


Using a sidecar container mounted into the same PID namespace with JDK built from this PR:

slovdahl at slovdahl-virtual-machine:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
root at 1ed0633e74eb:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
154 jdk.jcmd/sun.tools.jcmd.JCmd
root at 1ed0633e74eb:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Starting the target container with elevated privileges:

slovdahl at slovdahl-virtual-machine:~$ docker run --name reproducer --cap-add=CAP_NET_RAW --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81

slovdahl at slovdahl-virtual-machine:~$ sudo getpcaps 7332
7332: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep


Attaching from a sidecar container with a JDK built from this PR:

slovdahl at slovdahl-virtual-machine:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
root at 07d305e00ade:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2124549900

From rriggs at openjdk.org  Wed May 22 15:35:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 May 2024 15:35:07 GMT
Subject: RFR: 8332071: Convert package.html files in `java.management.rmi`
 to package-info.java [v5]
In-Reply-To: <m8Kt04mSOvAGYDjWtnkRakCynsl6qcI-Myi7YmotoSI=.8a7cd5f3-e3b1-4bc5-832b-236b36c77ea1@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
 <m8Kt04mSOvAGYDjWtnkRakCynsl6qcI-Myi7YmotoSI=.8a7cd5f3-e3b1-4bc5-832b-236b36c77ea1@github.com>
Message-ID: <K2oyI1rIy3hMfQ38O9oO2goQnTGL9OtzurvlsqzCFqI=.fb08b4a5-441e-4e35-824c-5c0f86af7a76@github.com>

On Mon, 20 May 2024 20:55:16 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
>> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
>> The conversion was done in-place, only renaming it in git.
>> 
>> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
>> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19263#pullrequestreview-2071636919

From nbenalla at openjdk.org  Wed May 22 16:34:13 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 22 May 2024 16:34:13 GMT
Subject: Integrated: 8332071: Convert package.html files in
 `java.management.rmi` to package-info.java
In-Reply-To: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
References: <C4TE2eJgcTkq3oSL28MUdXv5urkT5cTmLJmWBWsWLDo=.67b14a3e-98e1-46a7-8aa4-e1eb155aadc3@github.com>
Message-ID: <5-cZWgw3uTChugg_L6nSoBOqlLipVjSmgoXcQi9jVkw=.56df2e77-65d7-4ea4-a980-e830793e0ffe@github.com>

On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this change. I converted the `package.html` file to `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html).
> The conversion was done in-place, only renaming it in git.
> 
> I also added a couple of `@since` tags, with only 2 changes I don't want to split these two fixes into separate PRs.
> `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in https://bugs.openjdk.org/browse/JDK-8187556

This pull request has now been integrated.

Changeset: a0c5714d
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0c5714dbc8a60d905f9deea153e7f31fbd64d06
Stats:     675 lines in 3 files changed: 330 ins; 329 del; 16 mod

8332071: Convert package.html files in `java.management.rmi` to package-info.java
8332376: Add `@since` tags to `java.management.rmi`

Reviewed-by: kevinw, rriggs

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

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

From cjplummer at openjdk.org  Wed May 22 16:42:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 May 2024 16:42:02 GMT
Subject: RFR: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization
In-Reply-To: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
References: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
Message-ID: <uzZLiT1XBaAi9wCtMXOvzP35gtOkiPFYG4wgCV-c2Ok=.caea8ac2-2db7-4bcd-a723-448e9c74d309@github.com>

On Tue, 21 May 2024 19:55:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The BindServer starts several threads and opens streams.
> 
> It registered them for cleanup using "Finalizer" from nsk.share.framework. Currently, it cleanup resources during shutdown hook.
> 
> This fix changes BindServer to explicitly close streams and finish threads after test is completed. The exceptions are just printed like it was done previously. I haven't caught any exception during in close method during testing.

Looks good. Just one minor comment suggestion.

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java line 634:

> 632:         /**
> 633:          * Close thread by closing all connections and waiting
> 634:          * for thread finished.

Suggestion:

         * for thread to finish.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19335#pullrequestreview-2071799883
PR Review Comment: https://git.openjdk.org/jdk/pull/19335#discussion_r1610313535

From cjplummer at openjdk.org  Wed May 22 16:57:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 May 2024 16:57:10 GMT
Subject: RFR: 8332641: Update nsk.share.jpda.Jdb to don't use finalization
In-Reply-To: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
References: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
Message-ID: <IcKCSI484XsZ_ZZfuwsUXbcdv8gx7FHaT5C7u0j8RA0=.530c4ef5-6555-4ee6-8b6e-577d4e52339c@github.com>

On Tue, 21 May 2024 21:49:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.jdb.Jdb has finalize() nethods that close jdb connection and output streams.
> 
> The fix renames the method to close() and calls it explicitly after the test finishes. I verified that close() called for each nsk share jdb test.
> 
> The jdb is also LocalProcess with it's own cleanup(). This part still remains the same so far.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19336#pullrequestreview-2071834856

From cjplummer at openjdk.org  Wed May 22 17:46:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 May 2024 17:46:06 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <QiMfzOxXd7rcEA4MMGHb-CNT_2R2ypnvU6G2zxuNGaA=.6b68a2c3-1676-4516-a90f-63f7b6fe3aed@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
 <Hbd9xr14HDxTyrhkGXttxAwfME9Ntl1wCyoelpgS314=.be9ef44a-4278-450c-a8fa-50081cd1c5c1@github.com>
 <QiMfzOxXd7rcEA4MMGHb-CNT_2R2ypnvU6G2zxuNGaA=.6b68a2c3-1676-4516-a90f-63f7b6fe3aed@github.com>
Message-ID: <mP4OQckXFjF4XZ9aPaZJ-3qYSGkd8yuAYJVBSyb8eZI=.3e2632c7-a036-478c-82bd-a4aa4e8ac894@github.com>

On Thu, 16 May 2024 20:02:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Ironically right now I'm looking at a very rare deadlock that involves this code. It doesn't seem to happen when I disabled ranked locking. It might be instigated by the dbgRawMonitor that ranked locking uses.

@kevinjwalls I tracked down this deadlock and filed [JDK-8332738](https://bugs.openjdk.org/browse/JDK-8332738). It's really a pre-existing issue, but we get lucky with the current implementation because RawMonitorExit does not self suspend until after releasing the monitor, thus avoiding the deadlock. The ranked monitors implementation adds a self suspend opportunity when we release a raw monitor, which is it hits this bug. This is a very ugly issue that involves two threads getting events at the same time, and the debugger doing a StackFrame.PopFrames. Fortunately the "pop frames" locks are not involved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1610404920

From cjplummer at openjdk.org  Wed May 22 17:52:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 May 2024 17:52:08 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent.
 [v7]
In-Reply-To: <mP4OQckXFjF4XZ9aPaZJ-3qYSGkd8yuAYJVBSyb8eZI=.3e2632c7-a036-478c-82bd-a4aa4e8ac894@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
 <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com>
 <Hbd9xr14HDxTyrhkGXttxAwfME9Ntl1wCyoelpgS314=.be9ef44a-4278-450c-a8fa-50081cd1c5c1@github.com>
 <QiMfzOxXd7rcEA4MMGHb-CNT_2R2ypnvU6G2zxuNGaA=.6b68a2c3-1676-4516-a90f-63f7b6fe3aed@github.com>
 <mP4OQckXFjF4XZ9aPaZJ-3qYSGkd8yuAYJVBSyb8eZI=.3e2632c7-a036-478c-82bd-a4aa4e8ac894@github.com>
Message-ID: <ydE_iArPLI8G94s9dDAeB3JbJVQ5MiIzDHoxni5WEXo=.994eabe8-e9b2-4ec7-aa09-ee9eaa09c7d4@github.com>

On Wed, 22 May 2024 17:43:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> Is that "then popFrameEventLock second"
>>> 
>> Yes. I'll fix.
>> 
>>> Drawing these out in two columns I can't see a deadlock either 8-)
>> 
>> Ironically right now I'm looking at a very rare deadlock that involves this code. It doesn't seem to happen when I disabled ranked locking. It might be instigated by the dbgRawMonitor that ranked locking uses.
>
>> Ironically right now I'm looking at a very rare deadlock that involves this code. It doesn't seem to happen when I disabled ranked locking. It might be instigated by the dbgRawMonitor that ranked locking uses.
> 
> @kevinjwalls I tracked down this deadlock and filed [JDK-8332738](https://bugs.openjdk.org/browse/JDK-8332738). It's really a pre-existing issue, but we get lucky with the current implementation because RawMonitorExit does not self suspend until after releasing the monitor, thus avoiding the deadlock. The ranked monitors implementation adds a self suspend opportunity when we release a raw monitor, which is it hits this bug. This is a very ugly issue that involves two threads getting events at the same time, and the debugger doing a StackFrame.PopFrames. Fortunately the "pop frames" locks are not involved.

I should also add that this issue was only turning up when I had virtual threads enabled, because that caused one of the threads to trigger a class load of some CarrierThread inner class the first time it parked. This generated a ClassPrepare event with unfortunately timing (it would be on Thread 2 of my description in [JDK-8332738](https://bugs.openjdk.org/browse/JDK-8332738)). However, I now have a much more direct test that doesn't require virtual threads and more readily reproduces the deadlock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1610413014

From duke at openjdk.org  Wed May 22 18:45:06 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 22 May 2024 18:45:06 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
Message-ID: <eLyEg2744G58WVYJvWilp2-MFkYycx5EQftjkQJP3A8=.70b48802-81a8-4f55-8cdf-b48568592836@github.com>

On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

I haven't but I will BTW which linux capabilities should be enabled in 
order to prevent a /proc/... style attach due to lack of permissions to 
access target's /proc fs?

Rgds

- Larry

On 5/22/24 2:37 AM, Sebastian L?vdahl wrote:
>
> Thanks for the explanation @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufP1OzXcw$>, 
> that makes sense. By chance, did you already test the Docker |--user| 
> case with the suggested patch? I don't have access to an environment 
> with rootless Docker at hand, but I may be able to set it up in a VM 
> if you didn't already test it.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2124324590__;Iw!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufIAfBLoA$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67WR5PKR6GOLQ5YR4YTZDRRNVAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGMZDINJZGA__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufsOv7sDg$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------p6E1JhKjfAr6K0U0BUrS5J3x
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    I haven't but I will BTW which linux capabilities should be enabled
    in order to prevent a /proc/... style attach due to lack of
    permissions to access target's /proc fs?<br>
    <br>
    Rgds<br>
    <br>
    - Larry<br>
    <br>
    <div class="moz-cite-prefix">On 5/22/24 2:37 AM, Sebastian L?vdahl
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <p dir="auto">Thanks for the explanation <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufP1OzXcw$" ***@***.***</a>, that makes sense. By
        chance, did you already test the Docker <code class="notranslate">--user</code> case with the suggested
        patch? I don't have access to an environment with rootless
        Docker at hand, but I may be able to set it up in a VM if you
        didn't already test it.</p>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2124324590__;Iw!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufIAfBLoA$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67WR5PKR6GOLQ5YR4YTZDRRNVAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGMZDINJZGA__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufsOv7sDg$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67SYZIQHARL7TOTRLHLZDRRNVA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6T2PO4.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/19055/c2124324590</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124324590",
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124324590",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------p6E1JhKjfAr6K0U0BUrS5J3x--

it lives ...it lives!!!

I love it when a patch comes together!

:)

thx for testing this before my 1dt cup of coffee!

Rgds

- Larry

On 5/22/24 4:21 AM, Sebastian L?vdahl wrote:
>
> I set up rootless Docker in a VM by following 
> https://docs.docker.com/engine/security/rootless 
> <https://urldefense.com/v3/__https://docs.docker.com/engine/security/rootless__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoWGsleSZA$>.
>
> ***@***.***:~$ systemctl status --user 
> docker.service ? docker.service - Docker Application Container Engine 
> (Rootless) Loaded: loaded 
> (/home/slovdahl/.config/systemd/user/docker.service; enabled; vendor 
> preset: enabled) Active: active (running) since Wed 2024-05-22 
> 13:55:06 EEST; 5min ago Docs: https://docs.docker.com/go/rootless/ 
> <https://urldefense.com/v3/__https://docs.docker.com/go/rootless/__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoV88DoH1A$> 
> Main PID: 3314 (rootlesskit) Tasks: 58 Memory: 596.4M CPU: 16.821s 
> CGroup: 
> ***@***.***/app.slice/docker.service 
> ??3314 rootlesskit --state-dir=/run/user/1000/dockerd-rootless 
> --net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto 
> --slirp4netns-seccomp=auto --disable-host-loopback 
> --port-driver=builtin --copy-up=/etc --copy-up=/run 
> --propagation=rslave /usr/bin/dockerd> ??3325 /proc/self/exe 
> --state-dir=/run/user/1000/dockerd-rootless --net=slirp4netns 
> --mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto 
> --disable-host-loopback --port-driver=builtin --copy-up=/etc 
> --copy-up=/run --propagation=rslave /usr/bin/dock> ??3343 slirp4netns 
> --mtu 65520 -r 3 --disable-host-loopback --enable-sandbox 
> --enable-seccomp 3325 tap0 ??3350 dockerd ??3373 containerd --config 
> /run/user/1000/docker/containerd/containerd.toml ??4116 
> /usr/bin/containerd-shim-runc-v2 -namespace moby -id 
> 3a84c6c9f7b8ee6220b8953b65ff56639dd51335999cb37580292f4944ee0e65 
> -address /run/user/1000/docker/containerd/containerd.sock |
>
> Started a container running as my user:
>
> ***@***.***:~$ docker run --name reproducer 
> --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java Hello, 
> World! Bound to port 81 |
>
> Using the Ubuntu OpenJDK 17 package:
>
> ***@***.***:~$ java -version openjdk version 
> "17.0.10" 2024-01-16 OpenJDK Runtime Environment (build 
> 17.0.10+7-Ubuntu-122.04.1) OpenJDK 64-Bit Server VM (build 
> 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing) 
> ***@***.***:~$ jcmd 4139 
> jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java 5965 
> jdk.jcmd/sun.tools.jcmd.JCmd ***@***.***:~$ jcmd 
> 4139 VM.version 4139: OpenJDK 64-Bit Server VM version 17.0.11+9 JDK 
> 17.0.11 |
>
> Using mainline JDK without the changes in this PR:
>
> ***@***.***:~$ /jdk/bin/jcmd 4139 VM.version 
> 4139: OpenJDK 64-Bit Server VM version 17.0.11+9 JDK 17.0.11 |
>
> Using JDK built from this PR:
>
> ***@***.***:~$ /jdk/bin/jcmd 4139 VM.version 
> 4139: OpenJDK 64-Bit Server VM version 17.0.11+9 JDK 17.0.11 |
>
> Using a sidecar container mounted into the same PID namespace with 
> Eclipse Temurin 17:
>
> ***@***.***:~$ docker run --interactive --tty 
> --rm --pid=container:reproducer eclipse-temurin:17.0.11_9-jdk-jammy 
> /bin/bash ***@***.***:/# jcmd 44 jdk.jcmd/sun.tools.jcmd.JCmd 
> ***@***.***:/# jcmd 1 VM.version 1: OpenJDK 64-Bit Server VM 
> version 17.0.11+9 JDK 17.0.11 |
>
> Using a sidecar container mounted into the same PID namespace with 
> mainline JDK (expected to fail):
>
> ***@***.***:~$ docker run --interactive --tty 
> --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 
> /bin/bash ***@***.***:/# /jdk/bin/jcmd 1 
> jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java 234 
> jdk.jcmd/sun.tools.jcmd.JCmd ***@***.***:/# /jdk/bin/jcmd 1 
> VM.version 1: com.sun.tools.attach.AttachNotSupportedException: Unable 
> to open socket file /tmp/.java_pid1: target process 1 doesn't respond 
> within 10500ms or HotSpot VM not loaded at 
> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:99) 
> at 
> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) 
> at 
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) 
> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) at 
> jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) |
>
> Using a sidecar container mounted into the same PID namespace with JDK 
> built from this PR:
>
> ***@***.***:~$ docker run --interactive --tty 
> --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 
> /bin/bash ***@***.***:/# /jdk/bin/jcmd 1 
> jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java 154 
> jdk.jcmd/sun.tools.jcmd.JCmd ***@***.***:/# /jdk/bin/jcmd 1 
> VM.version 1: OpenJDK 64-Bit Server VM version 17.0.11+9 JDK 17.0.11 |
>
> Starting the target container with elevated privileges:
>
> ***@***.***:~$ docker run --name reproducer 
> --cap-add=CAP_NET_RAW --rm -v .:/app -w /app eclipse-temurin:17 java 
> Reproducer.java Hello, World! Bound to port 81 
> ***@***.***:~$ sudo getpcaps 7332 7332: 
> cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep 
> |
>
> Attaching from a sidecar container with a JDK built from this PR:
>
> ***@***.***:~$ docker run --interactive --tty 
> --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 
> /bin/bash ***@***.***:/# /jdk/bin/jcmd 1 VM.version 1: OpenJDK 
> 64-Bit Server VM version 17.0.11+9 JDK 17.0.11 |
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2124549900__;Iw!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoUiCnhWUw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VDJPJFFMPA7SF2YJDZDR5SLAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGU2DSOJQGA__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoWSMOTYwg$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------0k0wZisxTpAKNaSxRp0B1RTM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    it lives ...it lives!!! <br>
    <br>
    I love it when a patch comes together!<br>
    <br>
    :)<br>
    <br>
    thx for testing this before my 1dt cup of coffee!<br>
    <br>
    Rgds<br>
    <br>
    - Larry<br>
    <br>
    <div class="moz-cite-prefix">On 5/22/24 4:21 AM, Sebastian L?vdahl
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <p dir="auto">I set up rootless Docker in a VM by following <a href="https://urldefense.com/v3/__https://docs.docker.com/engine/security/rootless__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoWGsleSZA$" rel="nofollow" moz-do-not-send="true">https://docs.docker.com/engine/security/rootless</a>.</p>
      <pre class="notranslate"><code ***@***.***:~$ systemctl status --user docker.service 
? docker.service - Docker Application Container Engine (Rootless)
     Loaded: loaded (/home/slovdahl/.config/systemd/user/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-05-22 13:55:06 EEST; 5min ago
       Docs: <a href="https://urldefense.com/v3/__https://docs.docker.com/go/rootless/__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoV88DoH1A$" moz-do-not-send="true">https://docs.docker.com/go/rootless/</a>
   Main PID: 3314 (rootlesskit)
      Tasks: 58
     Memory: 596.4M
        CPU: 16.821s
     CGroup: ***@***.***/app.slice/docker.service
             ??3314 rootlesskit --state-dir=/run/user/1000/dockerd-rootless --net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin --copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dockerd&gt;
             ??3325 /proc/self/exe --state-dir=/run/user/1000/dockerd-rootless --net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin --copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dock&gt;
             ??3343 slirp4netns --mtu 65520 -r 3 --disable-host-loopback --enable-sandbox --enable-seccomp 3325 tap0
             ??3350 dockerd
             ??3373 containerd --config /run/user/1000/docker/containerd/containerd.toml
             ??4116 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 3a84c6c9f7b8ee6220b8953b65ff56639dd51335999cb37580292f4944ee0e65 -address /run/user/1000/docker/containerd/containerd.sock
</code></pre>
      <p dir="auto">Started a container running as my user:</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --name reproducer --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81
</code></pre>
      <p dir="auto">Using the Ubuntu OpenJDK 17 package:</p>
      <pre class="notranslate"><code ***@***.***:~$ java -version
openjdk version &quot;17.0.10&quot; 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)

***@***.***:~$ jcmd
4139 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
5965 jdk.jcmd/sun.tools.jcmd.JCmd

***@***.***:~$ jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p dir="auto">Using mainline JDK without the changes in this PR:</p>
      <pre class="notranslate"><code ***@***.***:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p dir="auto">Using JDK built from this PR:</p>
      <pre class="notranslate"><code ***@***.***:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p dir="auto">Using a sidecar container mounted into the same PID
        namespace with Eclipse Temurin 17:</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --interactive --tty --rm --pid=container:reproducer eclipse-temurin:17.0.11_9-jdk-jammy /bin/bash
***@***.***:/# jcmd
44 jdk.jcmd/sun.tools.jcmd.JCmd
***@***.***:/# jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p dir="auto">Using a sidecar container mounted into the same PID
        namespace with mainline JDK (expected to fail):</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
***@***.***:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
234 jdk.jcmd/sun.tools.jcmd.JCmd
***@***.***:/# /jdk/bin/jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.&lt;init&gt;(VirtualMachineImpl.java:99)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
</code></pre>
      <p dir="auto">Using a sidecar container mounted into the same PID
        namespace with JDK built from this PR:</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
***@***.***:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
154 jdk.jcmd/sun.tools.jcmd.JCmd
***@***.***:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p dir="auto">Starting the target container with elevated
        privileges:</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --name reproducer --cap-add=CAP_NET_RAW --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81

***@***.***:~$ sudo getpcaps 7332
7332: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
</code></pre>
      <p dir="auto">Attaching from a sidecar container with a JDK built
        from this PR:</p>
      <pre class="notranslate"><code ***@***.***:~$ docker run --interactive --tty --rm --pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
***@***.***:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11
</code></pre>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2124549900__;Iw!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoUiCnhWUw$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VDJPJFFMPA7SF2YJDZDR5SLAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGU2DSOJQGA__;!!ACWV5N9M2RV99hQ!ILXmNJIu4Gt289mnC35eZVQJfnEjBLKSgmLkd-qoanr6YXVS7KHjYw24PXzZbOdX1IT4HTFNICDXNnKMIoWSMOTYwg$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67TJSKIPHAMPXJIXIXTZDR5SLA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6UIHQY.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/19055/c2124549900</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124549900",
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124549900",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------0k0wZisxTpAKNaSxRp0B1RTM--

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2125504036
PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2125516312

From duke at openjdk.org  Wed May 22 19:01:02 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 22 May 2024 19:01:02 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <eLyEg2744G58WVYJvWilp2-MFkYycx5EQftjkQJP3A8=.70b48802-81a8-4f55-8cdf-b48568592836@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
 <eLyEg2744G58WVYJvWilp2-MFkYycx5EQftjkQJP3A8=.70b48802-81a8-4f55-8cdf-b48568592836@github.com>
Message-ID: <KezgxLN06_qKs7gAYhVi5uoqAXXsyKn6Fi7Oq1PQ1e8=.4c9b83b9-1dd5-476b-bf9e-8a919d0dd54c@github.com>

On Wed, 22 May 2024 18:40:00 GMT, Larry Cable <duke at openjdk.org> wrote:

> I haven't but I will BTW which linux capabilities should be enabled in order to prevent a /proc/... style attach due to lack of permissions to access target's /proc fs? Rgds - Larry

I know for sure that `CAP_NET_BIND_SERVICE` prevents access to `/proc/<pid>/root` at least. I don't know if there's any distinction between the different privileges a process can have to be honest, but I somehow got the impression that having _any_ privilege restricts access to `/proc/<pid>/root` (among others). But right now I cannot recall what gave me that impression. There's a long list of capabilities though: https://man7.org/linux/man-pages/man7/capabilities.7.html

> it lives ...it lives!!!
>
> I love it when a patch comes together!
> 
> :)
> 
> thx for testing this before my 1dt cup of coffee!

Great feeling indeed! Ah, the best cup of the day, have a good one :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2125541556

From duke at openjdk.org  Wed May 22 19:07:03 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 22 May 2024 19:07:03 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v3]
In-Reply-To: <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <k9jeW2PWy7OiFyWBKBVfaC0Tfmq3w-7wdYcmW4X-RRE=.fc000bcf-466c-4e9c-86ac-391d4cb19c7b@github.com>
Message-ID: <2bsbTtQdRtS8h0ZORSgd163bHp1PZNTNiUiF_SGelZY=.618a5098-4111-4eb4-ac8d-1c02538d6a80@github.com>

On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

On 5/22/24 11:58 AM, Sebastian L?vdahl wrote:
>
>     I haven't but I will BTW which linux capabilities should be
>     enabled in order to prevent a /proc/... style attach due to lack
>     of permissions to access target's /proc fs? Rgds - Larry
>
> I know for sure that |CAP_NET_BIND_SERVICE| prevents access to 
> |/proc/<pid>/root| at least. I don't know if there's any distinction 
> between the different privileges a process can have to be honest, but 
> I somehow got the impression that having /any/ privilege restricts 
> access to |/proc/<pid>/root| (among others). But right now I cannot 
> recall what gave me that impression. There's a long list of 
> capabilities though: 
> https://man7.org/linux/man-pages/man7/capabilities.7.html 
> <https://urldefense.com/v3/__https://man7.org/linux/man-pages/man7/capabilities.7.html__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JV3zd5SA$>
>
>     it lives ...it lives!!!
>
>     I love it when a patch comes together!
>
>     :)
>
>     thx for testing this before my 1dt cup of coffee!
>
> Great feeling indeed! Ah, the best cup of the day, have a good one :)
>

likewise Slainte Mhath!

- Larry

> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2125541556__;Iw!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JG0EA7Zg$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VJZL3MIT2HANZ3BLDZDTTG7AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGU2DCNJVGY__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0IYrO2-pA$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------Rdb42IWaMAGxS5O004yPY6ws
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/22/24 11:58 AM, Sebastian L?vdahl
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <blockquote>
        <p dir="auto">I haven't but I will BTW which linux capabilities
          should be enabled in order to prevent a /proc/... style attach
          due to lack of permissions to access target's /proc fs? Rgds -
          Larry</p>
      </blockquote>
      <p dir="auto">I know for sure that <code class="notranslate">CAP_NET_BIND_SERVICE</code>
        prevents access to <code class="notranslate">/proc/&lt;pid&gt;/root</code>
        at least. I don't know if there's any distinction between the
        different privileges a process can have to be honest, but I
        somehow got the impression that having <em>any</em> privilege
        restricts access to <code class="notranslate">/proc/&lt;pid&gt;/root</code>
        (among others). But right now I cannot recall what gave me that
        impression. There's a long list of capabilities though: <a href="https://urldefense.com/v3/__https://man7.org/linux/man-pages/man7/capabilities.7.html__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JV3zd5SA$" rel="nofollow" moz-do-not-send="true">https://man7.org/linux/man-pages/man7/capabilities.7.html</a></p>
      <blockquote>
        <p dir="auto">it lives ...it lives!!!</p>
        <p dir="auto">I love it when a patch comes together!</p>
        <p dir="auto">:)</p>
        <p dir="auto">thx for testing this before my 1dt cup of coffee!</p>
      </blockquote>
      <p dir="auto">Great feeling indeed! Ah, the best cup of the day,
        have a good one :)</p>
    </blockquote>
    <br>
    likewise Slainte Mhath!<br>
    <br>
    - Larry<br>
    <br>
    <blockquote type="cite" ***@***.***">
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2125541556__;Iw!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JG0EA7Zg$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VJZL3MIT2HANZ3BLDZDTTG7AVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGU2DCNJVGY__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0IYrO2-pA$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67VXC2SXHYIOCXNVH3DZDTTG7A5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6WEYLI.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/19055/c2125541556</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2125541556",
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2125541556",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------Rdb42IWaMAGxS5O004yPY6ws--

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2125551168

From kcr at openjdk.org  Wed May 22 21:45:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 May 2024 21:45:10 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I tested this with JavaFX and everything is working as I would expect. Without any options, I get the expected warnings, one time per modules for the three `javafx.*` modules that use JNI. If I pass the `--enable-native-access` options at runtime, listing those three modules, there is no warning. Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2072430338

From alanb at openjdk.org  Thu May 23 06:23:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 06:23:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
Message-ID: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>

On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.

Great! What about jpackage without a custom runtime, wondering if --java-options can be tested.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2126320311

From alanb at openjdk.org  Thu May 23 07:06:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 07:06:05 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v7]
In-Reply-To: <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
Message-ID: <1vdMcmqpKuTGl0jRRa4_hI3ui2UZtZRHHZRsXzstuHc=.be4a18d0-03b9-451d-afff-d9da94539a1f@github.com>

On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: UNDO: removed incorrect simplification that removed a tmp local skipped

Spec + code changes look okay. I didn't study the tests closely but I see you have updated the test coverage to ensure that virtual threads are not reported as the owner, waiting to enter, or waiting to be notified.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19030#pullrequestreview-2073032052

From sspitsyn at openjdk.org  Thu May 23 09:20:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 May 2024 09:20:05 GMT
Subject: RFR: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage [v7]
In-Reply-To: <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
 <F3zfmviP51eZaZaxBlUbkWKhX0oCR9aqkG2QvCYDBxk=.2d616209-ce81-4aaa-909a-28fc5c221bde@github.com>
Message-ID: <li9s6h9ztOLovrmAKd_aSbtXVyP3cqgZ7eDfVlB85Kw=.bb5a2b0b-f8c6-46cb-8e94-2eace9670952@github.com>

On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: UNDO: removed incorrect simplification that removed a tmp local skipped

Thank you for review, Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/19030#issuecomment-2126628322

From sspitsyn at openjdk.org  Thu May 23 12:10:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 May 2024 12:10:08 GMT
Subject: Integrated: 8328083: degrade virtual thread support for
 GetObjectMonitorUsage
In-Reply-To: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com>
Message-ID: <ViX9yWsZ2qmuLyvUXZ69wa3hJwvr0k8uekC7D4Uy1LI=.be17c126-002e-44ec-89d4-a14d7dab4679@github.com>

On Wed, 1 May 2024 10:20:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
> 
> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
> 
> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
> 
> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
> 
> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
> 
> Also, please, review the related CSR and Release Note:
> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
> 
> Testing:
>  - tested impacted and updated tests locally
>  - tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: b890336e
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b890336e111ea8473ae49e9992bc2fd61e716792
Stats:     188 lines in 12 files changed: 131 ins; 2 del; 55 mod

8328083: degrade virtual thread support for GetObjectMonitorUsage

Reviewed-by: cjplummer, alanb

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

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

From sspitsyn at openjdk.org  Thu May 23 13:16:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 May 2024 13:16:02 GMT
Subject: RFR: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization
In-Reply-To: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
References: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
Message-ID: <zWTA4iky3XNUqvumLQZYz11lAYkYN0VFfdQ6burcznw=.26579447-5cbe-4087-bad6-20b91d153d71@github.com>

On Tue, 21 May 2024 19:55:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The BindServer starts several threads and opens streams.
> 
> It registered them for cleanup using "Finalizer" from nsk.share.framework. Currently, it cleanup resources during shutdown hook.
> 
> This fix changes BindServer to explicitly close streams and finish threads after test is completed. The exceptions are just printed like it was done previously. I haven't caught any exception during in close method during testing.

Looks good. Posted one nit though.

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java line 388:

> 386:      * @see ServingThread
> 387:      */
> 388:     private static class ListeningThread extends Thread implements AutoCloseable{

Nit: Space is missed before '{'.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19335#pullrequestreview-2073933557
PR Review Comment: https://git.openjdk.org/jdk/pull/19335#discussion_r1611671166

From kcr at openjdk.org  Thu May 23 14:00:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 May 2024 14:00:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
 <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
Message-ID: <nbhSCeRioIjK1ko19ohj2andX49zn9W9hqj5E1dWOI0=.3bd6f07a-0df5-42b8-aed2-44a3127b85c5@github.com>

On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.
> 
> Great! What about jpackage without a custom runtime, wondering if --java-options can be tested.

Yes, pointing to an existing runtime works, too. In either mode (jpackage using an existing Java runtime vs running jlink to create a new one), the options specified by `jpackage --java-options` are written to the application's `.cfg` file and used when the application launcher is run.

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

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2127188783

From amenkov at openjdk.org  Fri May 24 00:35:05 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 24 May 2024 00:35:05 GMT
Subject: Integrated: 8331683: Clean up GetCarrierThread
In-Reply-To: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
References: <Y8DIErJ7H51foO1zsK-0spfW7ouhENrh4T7AzW0LFQI=.f1fbbef1-6512-444e-b7d6-35e382821d11@github.com>
Message-ID: <eH_ACTkwfpF16xVo4apOYMpJWUjd-R6OOSQbH70HdhE=.2caf9250-e89e-4185-99c1-6694dff530b4@github.com>

On Sat, 18 May 2024 00:47:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JVMTI GetCarrierThread extension function was introduced by loom for testing.
> It's used by several tests in hotspot/jtreg/serviceability.
> 
> Testings: tier1..tier6

This pull request has now been integrated.

Changeset: 424eb60d
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/424eb60dedb332237b8ec97e9da6bd95442c0083
Stats:     37 lines in 3 files changed: 4 ins; 27 del; 6 mod

8331683: Clean up GetCarrierThread

Reviewed-by: sspitsyn, cjplummer

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

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

From kevinw at openjdk.org  Fri May 24 08:56:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 08:56:04 GMT
Subject: RFR: 8332641: Update nsk.share.jpda.Jdb to don't use finalization
In-Reply-To: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
References: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
Message-ID: <ACPnMUVnUsUc1MkLyJYiLdjdw9TX2GSYqTcqyPtgULc=.ec8f7a84-b983-4f67-8eb2-e20cfc8d643d@github.com>

On Tue, 21 May 2024 21:49:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.jdb.Jdb has finalize() nethods that close jdb connection and output streams.
> 
> The fix renames the method to close() and calls it explicitly after the test finishes. I verified that close() called for each nsk share jdb test.
> 
> The jdb is also LocalProcess with it's own cleanup(). This part still remains the same so far.

Looks good to me.
Nice that you can correct the typo where one of the JdbTest.java log lines was saying finalize instead of killDebuggee. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19336#pullrequestreview-2076278959

From duke at openjdk.org  Fri May 24 12:56:10 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 24 May 2024 12:56:10 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v12]
In-Reply-To: <27qGzorWxtdq6HLmIMPLHZ6_qRbOZo2DvA7pewZfNKA=.3f11daeb-1645-466e-b4bb-56aab62021b2@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <jndqQQhaWY-AdOhgwSqkFxJeAEulSap-QrT9OiB4GQc=.cfa532f4-6894-4946-b687-aafd82268dbf@github.com>
 <27qGzorWxtdq6HLmIMPLHZ6_qRbOZo2DvA7pewZfNKA=.3f11daeb-1645-466e-b4bb-56aab62021b2@github.com>
Message-ID: <z4GtjvtObSHPMuOLNcpOqUVdGAXxxFc8F7zqJVMWF10=.512af1ed-d32a-4ec7-8479-eb1a646ada29@github.com>

On Tue, 21 May 2024 06:08:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lei Zaakjyu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   restore
>
> test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java line 90:
> 
>> 88:         // before dumping the string table. That means the heap should contain no
>> 89:         // humongous regions.
>> 90:         dumpOutput.shouldNotMatch("gc,region,cds. G1HeapRegion 0x[0-9a-f]* HUM");
> 
> Just a minor nit. I noticed a pre-existing typo on line 87 above. It says "kelp" instead of "kept". Can you fix it?

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1613437928

From duke at openjdk.org  Fri May 24 13:04:14 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 24 May 2024 13:04:14 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v13]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - review
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
 - restore
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
 - review
 - Merge branch 'master' into JDK-8330694
 - fix indentation
 - also tidy up
 - tidy up
 - rename

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

Changes: https://git.openjdk.org/jdk/pull/18871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18871&range=12
  Stats: 1003 lines in 123 files changed: 1 ins; 4 del; 998 mod
  Patch: https://git.openjdk.org/jdk/pull/18871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18871/head:pull/18871

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

From tschatzl at openjdk.org  Fri May 24 13:15:04 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 May 2024 13:15:04 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v13]
In-Reply-To: <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
Message-ID: <kIi6RFUu9iD5_3v1GRtIn100gXYgQg88uONjqPHtB68=.3c8092f2-4c73-4084-92db-0074bed49266@github.com>

On Fri, 24 May 2024 13:04:14 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - review
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - restore
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - review
>  - Merge branch 'master' into JDK-8330694
>  - fix indentation
>  - also tidy up
>  - tidy up
>  - rename

Still good imo

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2076897185

From cjplummer at openjdk.org  Fri May 24 15:33:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 15:33:07 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v13]
In-Reply-To: <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
Message-ID: <eEtxKxuR7opGYir7lI_Kl20lJ-QSJ1dHhHBx7K3jj4A=.5c349fa9-0a52-407a-89ee-15566c5dce57@github.com>

On Fri, 24 May 2024 13:04:14 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - review
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - restore
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - review
>  - Merge branch 'master' into JDK-8330694
>  - fix indentation
>  - also tidy up
>  - tidy up
>  - rename

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2077242456

From cjplummer at openjdk.org  Fri May 24 15:53:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 15:53:07 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
Message-ID: <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>

On Fri, 17 May 2024 10:35:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add an 'also'
>>  - typo
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:
> 
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>> 960:      * array is also accepted for compatibility reasons, which must not
>> 961:      * contain any non-null entries.
> 
> The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.

How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613693492

From duke at openjdk.org  Fri May 24 15:55:07 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 24 May 2024 15:55:07 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v13]
In-Reply-To: <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
Message-ID: <e8r9mrwsjUTKPWpFVnCpaeWnmdQpWBq6g5QbgIEs00U=.0f5e6a77-52ca-454d-8c5e-531c69ade28a@github.com>

On Fri, 24 May 2024 13:04:14 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - review
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - restore
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - review
>  - Merge branch 'master' into JDK-8330694
>  - fix indentation
>  - also tidy up
>  - tidy up
>  - rename

thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2129876471

From kevinw at openjdk.org  Fri May 24 16:46:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 16:46:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
Message-ID: <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>

On Fri, 24 May 2024 15:50:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:
>> 
>>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>>> 960:      * array is also accepted for compatibility reasons, which must not
>>> 961:      * contain any non-null entries.
>> 
>> The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.
>
> How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.

Thanks, appreciate the effort trying to make it perfect.  
Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.

In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  

I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613758498

From cjplummer at openjdk.org  Fri May 24 16:52:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 16:52:02 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
 <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
Message-ID: <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>

On Fri, 24 May 2024 16:43:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.
>
> Thanks, appreciate the effort trying to make it perfect.  
> Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.
> 
> In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  
> 
> I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).

For me the main hold up is using "should". Maybe:

"Must be null or an array that doesn't contain any non-null entries."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613765813

From kevinw at openjdk.org  Fri May 24 17:08:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 17:08:01 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v3]
In-Reply-To: <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
 <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
 <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>
Message-ID: <AbC_NLgPFbULTaHLQwZ_vSwpmDISEdhjfYOdesRwOGc=.dd7de88d-38d8-456c-82f4-9cded5567b7d@github.com>

On Fri, 24 May 2024 16:49:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thanks, appreciate the effort trying to make it perfect.  
>> Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.
>> 
>> In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  
>> 
>> I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).
>
> For me the main hold up is using "should". Maybe:
> 
> "Must be null or an array that doesn't contain any non-null entries."

OK I think I can get rid of "should"....

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613782613

From kevinw at openjdk.org  Fri May 24 17:15:31 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 17:15:31 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v5]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  remove should... from delegationSubjects param

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/4e8f84ec..646a0d96

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

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

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

From lmesnik at openjdk.org  Fri May 24 17:34:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:34:07 GMT
Subject: RFR: 8332641: Update nsk.share.jpda.Jdb to don't use finalization
In-Reply-To: <IcKCSI484XsZ_ZZfuwsUXbcdv8gx7FHaT5C7u0j8RA0=.530c4ef5-6555-4ee6-8b6e-577d4e52339c@github.com>
References: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
 <IcKCSI484XsZ_ZZfuwsUXbcdv8gx7FHaT5C7u0j8RA0=.530c4ef5-6555-4ee6-8b6e-577d4e52339c@github.com>
Message-ID: <1K5FynuvJABubIBQh8Lu-GW_8aM2RfAhWsbMsGH85EY=.c2fd0ac7-dda3-47d6-9fd2-628521e62fb4@github.com>

On Wed, 22 May 2024 16:54:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The nsk.share.jdb.Jdb has finalize() nethods that close jdb connection and output streams.
>> 
>> The fix renames the method to close() and calls it explicitly after the test finishes. I verified that close() called for each nsk share jdb test.
>> 
>> The jdb is also LocalProcess with it's own cleanup(). This part still remains the same so far.
>
> Looks good.

@plummercj, @kevinjwalls Thank you for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/19336#issuecomment-2130052548

From lmesnik at openjdk.org  Fri May 24 17:34:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:34:07 GMT
Subject: Integrated: 8332641: Update nsk.share.jpda.Jdb to don't use
 finalization
In-Reply-To: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
References: <lOOQzcFPNW2HfM1YEfZnwI8PLYOImiGCCAikziWRodw=.764ad22f-7e02-4de0-b884-06d3c5703401@github.com>
Message-ID: <3a4RK-RZxdsky10_not8wSxW4O76U5uzjC-f-4YJuRE=.9603687e-4c51-4546-b176-d74ec924b6d9@github.com>

On Tue, 21 May 2024 21:49:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.jdb.Jdb has finalize() nethods that close jdb connection and output streams.
> 
> The fix renames the method to close() and calls it explicitly after the test finishes. I verified that close() called for each nsk share jdb test.
> 
> The jdb is also LocalProcess with it's own cleanup(). This part still remains the same so far.

This pull request has now been integrated.

Changeset: f66a5866
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f66a58661459bf64212ec332540c12d5d691270f
Stats:     25 lines in 2 files changed: 8 ins; 7 del; 10 mod

8332641: Update nsk.share.jpda.Jdb to don't use finalization

Reviewed-by: cjplummer, kevinw

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

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

From lmesnik at openjdk.org  Fri May 24 17:36:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:36:20 GMT
Subject: RFR: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization [v2]
In-Reply-To: <uzZLiT1XBaAi9wCtMXOvzP35gtOkiPFYG4wgCV-c2Ok=.caea8ac2-2db7-4bcd-a723-448e9c74d309@github.com>
References: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
 <uzZLiT1XBaAi9wCtMXOvzP35gtOkiPFYG4wgCV-c2Ok=.caea8ac2-2db7-4bcd-a723-448e9c74d309@github.com>
Message-ID: <sAS8Gui2bZtW7yZCAcRMRpqZvu8cNite0gZR-x4kcgA=.e4a867d8-830b-4a0c-a7dc-dd90aba296bd@github.com>

On Wed, 22 May 2024 16:39:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge branch '8332631' of https://github.com/lmesnik/jdk into 8332631
>>  - Update test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
>>    
>>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>>  - added space
>
> Looks good. Just one minor comment suggestion.

@plummercj, @sspitsyn Thank you for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/19335#issuecomment-2130056783

From lmesnik at openjdk.org  Fri May 24 17:36:19 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:36:19 GMT
Subject: RFR: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization [v2]
In-Reply-To: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
References: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
Message-ID: <nYgGHtttRTA8ZKbpEj-LRS6O-5mGewcj-_6FgOLK4ZA=.80db426e-d1ee-4203-ba2c-c3424c3025de@github.com>

> The BindServer starts several threads and opens streams.
> 
> It registered them for cleanup using "Finalizer" from nsk.share.framework. Currently, it cleanup resources during shutdown hook.
> 
> This fix changes BindServer to explicitly close streams and finish threads after test is completed. The exceptions are just printed like it was done previously. I haven't caught any exception during in close method during testing.

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

 - Merge branch '8332631' of https://github.com/lmesnik/jdk into 8332631
 - Update test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
   
   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
 - added space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19335/files
  - new: https://git.openjdk.org/jdk/pull/19335/files/eeeb59ff..c18445aa

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

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

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

From lmesnik at openjdk.org  Fri May 24 17:36:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:36:20 GMT
Subject: Integrated: 8332631: Update nsk.share.jpda.BindServer to don't use
 finalization
In-Reply-To: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
References: <JeY6ZIT7LYBJHgGTugPg3UANY-OC7QFuFRWtVOOSRo0=.7ff7e6e8-f780-409b-8f35-2829f27231a2@github.com>
Message-ID: <ruY3Kmo4h6lelGsRyFiSoCmWcYetNHa_99Y_GBL7L00=.28af2b1f-1943-4f61-8b08-b37e456068b8@github.com>

On Tue, 21 May 2024 19:55:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The BindServer starts several threads and opens streams.
> 
> It registered them for cleanup using "Finalizer" from nsk.share.framework. Currently, it cleanup resources during shutdown hook.
> 
> This fix changes BindServer to explicitly close streams and finish threads after test is completed. The exceptions are just printed like it was done previously. I haven't caught any exception during in close method during testing.

This pull request has now been integrated.

Changeset: b3b33667
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3b33667ad3bdb7be868fb165a1ea53054947cd0
Stats:     98 lines in 1 file changed: 18 ins; 54 del; 26 mod

8332631: Update nsk.share.jpda.BindServer to don't use finalization

Reviewed-by: cjplummer, sspitsyn

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

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

From cjplummer at openjdk.org  Fri May 24 18:08:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 18:08:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v5]
In-Reply-To: <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
Message-ID: <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>

On Fri, 24 May 2024 17:15:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove should... from delegationSubjects param

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 978:

> 976:      * @throws IOException if a general communication exception occurred.
> 977:      * @throws UnsupportedOperationException if {@code delegationSubjects}
> 978:      * is non-null and contains any non-null values.

Minor consistency issue. For the `delegationSubjects` comment above, you refer to "non-null entries". Here you refer to "non-null values". I don't have a preference on which you use, but they should be the same in both cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613843199

From kevinw at openjdk.org  Fri May 24 18:22:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 18:22:18 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v6]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  entries consistency in param and throws text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/646a0d96..0b0164e3

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

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

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

From kevinw at openjdk.org  Fri May 24 18:22:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 18:22:18 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v5]
In-Reply-To: <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
 <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>
Message-ID: <DTENmbPnUQBOCkdE7ir6m3AM93sBwLSxP9PrHA1boqQ=.14149f49-0a8a-4ec6-b00a-6599c0274842@github.com>

On Fri, 24 May 2024 18:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove should... from delegationSubjects param
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 978:
> 
>> 976:      * @throws IOException if a general communication exception occurred.
>> 977:      * @throws UnsupportedOperationException if {@code delegationSubjects}
>> 978:      * is non-null and contains any non-null values.
> 
> Minor consistency issue. For the `delegationSubjects` comment above, you refer to "non-null entries". Here you refer to "non-null values". I don't have a preference on which you use, but they should be the same in both cases.

OK I'll change the "values" in the throws clause to be "entries", to be consistent, to keep this moving...
(But I don't think there was any possible confusion here. 8-) )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613856276

From cjplummer at openjdk.org  Fri May 24 18:58:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 18:58:02 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v6]
In-Reply-To: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
Message-ID: <m6nuG1Bi6Pcf1o09V8WPfXlUm1wSYwPHXiCp1yHOFN8=.776f6128-219f-4764-87ee-88e88c652909@github.com>

On Fri, 24 May 2024 18:22:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   entries consistency in param and throws text

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2077642914

From kevinw at openjdk.org  Fri May 24 19:19:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 19:19:03 GMT
Subject: RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation [v6]
In-Reply-To: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
Message-ID: <eyZHzPodLy7CsqdWV1Szu3UqA_R_UOtbki7XdllC0b4=.e0bfca36-450f-48b5-8de7-4c6e078c9a64@github.com>

On Fri, 24 May 2024 18:22:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   entries consistency in param and throws text

Thanks Chris, and Daniel, for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2130210171

From kevinw at openjdk.org  Fri May 24 19:34:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 19:34:07 GMT
Subject: Integrated: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <z9z-_Ki_J7XJRFiPNVDWzrK1m2MuIdNnsIWwOOpQLvc=.9537b1cd-891f-4450-85cf-c4be6bf55000@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

This pull request has now been integrated.

Changeset: 253508b0
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/253508b03a3de4dab00ed7fb57e9f345d8aed1a4
Stats:     19 lines in 2 files changed: 8 ins; 3 del; 8 mod

8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation

Reviewed-by: dfuchs, cjplummer

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

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

From nbenalla at openjdk.org  Fri May 24 19:54:34 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 24 May 2024 19:54:34 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java
Message-ID: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>

This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.

Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.

I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".

I am referring to line 69 in 
`src/java.management/share/classes/javax/management/monitor/package-info.java`
and lines 90 and 120 in 
`src/java.management/share/classes/javax/management/remote/package-info.java`

Adding 2 dependencies just for 3 links didn't seem right.

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

Commit messages:
 - 8332070: Convert package.html files in `java.management` to package-info.java

Changes: https://git.openjdk.org/jdk/pull/19399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332070
  Stats: 3091 lines in 18 files changed: 1526 ins; 1565 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19399/head:pull/19399

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

From cjplummer at openjdk.org  Fri May 24 20:12:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 20:12:23 GMT
Subject: RFR: 8332919: SA PointerLocation needs to print a newline after
 dumping java thread info for JNI Local
Message-ID: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>

If PointerLocation discovers that an address is for a JNI local ref, it will print information about the thread that owns the JNI local ref. For JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on the call that says that it 'includes "\n"'. This is actually not true, and a separate println() is needed. I noticed this when using the clhsdb findpc command on a JNI local ref and noted that the next "hdsb> " prompt was printed at the end of the findpc output instead of on a new line.

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

Commit messages:
 - Need a newline after printThreadIDOn() call

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

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

From kbarrett at openjdk.org  Sat May 25 02:13:18 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 25 May 2024 02:13:18 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v13]
In-Reply-To: <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <cLU6fo7hGjzFdHgpbnlqs6Hv_z57Vhnxt7qB666xlnw=.8615cf2e-c224-40ea-9509-86654911c907@github.com>
Message-ID: <JJeAmsVKGLBFSRZl1iOGRPruiWgHZpJ5I-DQU9hRG_I=.944f99ed-4c8f-44bb-a8bb-4e8934129d6d@github.com>

On Fri, 24 May 2024 13:04:14 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - review
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - restore
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
>  - review
>  - Merge branch 'master' into JDK-8330694
>  - fix indentation
>  - also tidy up
>  - tidy up
>  - rename

Still looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2078316714

From duke at openjdk.org  Sat May 25 02:13:19 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 25 May 2024 02:13:19 GMT
Subject: Integrated: 8330694: Rename 'HeapRegion' to 'G1HeapRegion'
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <zsne1caDvfuSx0pxNFdjWrQnm4wQpc8YMVsJHZSPbEc=.b9bec7e9-3323-4ee7-9d52-8f0a33563f83@github.com>

On Sat, 20 Apr 2024 02:04:20 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> follow up 8267941

This pull request has now been integrated.

Changeset: 985b9ce7
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/985b9ce79a2d620a8b8675d1ae6c9730d72a757f
Stats:     1003 lines in 123 files changed: 1 ins; 4 del; 998 mod

8330694: Rename 'HeapRegion' to 'G1HeapRegion'

Reviewed-by: cjplummer, kbarrett, tschatzl

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

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

From alanb at openjdk.org  Sat May 25 06:24:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 25 May 2024 06:24:01 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java
In-Reply-To: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
References: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
Message-ID: <1yAgwfJSgliYle4CXHHjxxtt8RunI0ltJGeo3fWc1Po=.afbf812e-1cd0-4579-a68c-55aade840c11@github.com>

On Fri, 24 May 2024 18:11:18 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.
> 
> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.
> 
> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".
> 
> I am referring to line 69 in 
> `src/java.management/share/classes/javax/management/monitor/package-info.java`
> and lines 90 and 120 in 
> `src/java.management/share/classes/javax/management/remote/package-info.java`
> 
> Adding 2 dependencies just for 3 links didn't seem right.
> 
> edit: tier 1 passes on my machine, will check why a certain test fails later. As this change shouldn't cause breakage
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1_serviceability       353   353     0     0   
> ==============================
> TEST SUCCESS

src/java.management/share/classes/java/lang/management/package-info.java line 27:

> 25: 
> 26: /**
> 27:  *   Provides the management interfaces for monitoring and management of the

I assume you used a script to convert these, I'm just curious why puts two spaces after the *, the usual convention is one. It's not a big deal but if this is something that can be fixed in the scripts then it would avoid a future cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19399#discussion_r1614381819

From nbenalla at openjdk.org  Sat May 25 10:07:02 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 25 May 2024 10:07:02 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java
In-Reply-To: <1yAgwfJSgliYle4CXHHjxxtt8RunI0ltJGeo3fWc1Po=.afbf812e-1cd0-4579-a68c-55aade840c11@github.com>
References: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
 <1yAgwfJSgliYle4CXHHjxxtt8RunI0ltJGeo3fWc1Po=.afbf812e-1cd0-4579-a68c-55aade840c11@github.com>
Message-ID: <4G0s6AJ48OWsYAY69RWF-ulcuvbQkuNjRBGwy0DPNJQ=.921b93df-e162-4f04-bba0-cc8e0a4f6aeb@github.com>

On Sat, 25 May 2024 06:21:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.
>> 
>> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.
>> 
>> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
>> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".
>> 
>> I am referring to line 69 in 
>> `src/java.management/share/classes/javax/management/monitor/package-info.java`
>> and lines 90 and 120 in 
>> `src/java.management/share/classes/javax/management/remote/package-info.java`
>> 
>> Adding 2 dependencies just for 3 links didn't seem right.
>> 
>> edit: tier 1 passes on my machine, will check why a certain test fails later. As this change shouldn't cause breakage
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/hotspot/jtreg:tier1_serviceability       353   353     0     0   
>> ==============================
>> TEST SUCCESS
>
> src/java.management/share/classes/java/lang/management/package-info.java line 27:
> 
>> 25: 
>> 26: /**
>> 27:  *   Provides the management interfaces for monitoring and management of the
> 
> I assume you used a script to convert these, I'm just curious why puts two spaces after the *, the usual convention is one. It's not a big deal but if this is something that can be fixed in the scripts then it would avoid a future cleanup.

I think it can be fixed, I just thought one space looked cramped

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19399#discussion_r1614530454

From syan at openjdk.org  Sun May 26 09:34:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 09:34:12 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
Message-ID: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>

Hi all,
  ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. It should be predicated with `@requires vm.continuations` to be skipped.

Additional testing:
- [x] linux x86_32, test has been skiped.
- [x] linux x86_64, test still work.

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

Commit messages:
 - 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count

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

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

From alanb at openjdk.org  Sun May 26 11:29:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 May 2024 11:29:00 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
Message-ID: <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>

On Sun, 26 May 2024 09:27:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. It should be predicated with `@requires vm.continuations` to be skipped.
> 
> Additional testing:
> - [x] linux x86_32, test has been skiped.
> - [x] linux x86_64, test still work.

That would mean it's not tested. I suspect the  java_lang_VirtualThread::is_instance checks will need to be changed to test with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the alternative implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2132184808

From syan at openjdk.org  Sun May 26 14:27:01 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 14:27:01 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>
Message-ID: <-tbpkfcDNMlCE7lUDqrl2B_hKofsWED6q8ynzdyA62Q=.5f14044d-209e-4ac7-b019-47b8e597af70@github.com>

On Sun, 26 May 2024 11:26:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> That would mean it's not tested. I suspect the java_lang_VirtualThread::is_instance checks will need to be changed to test with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the alternative implementation.

Do you mean change like this:

diff --git a/src/hotspot/share/classfile/javaClasses.cpp b/src/hotspot/share/classfile/javaClasses.cpp
index 077b05f936e..c03bb511e2a 100644
--- a/src/hotspot/share/classfile/javaClasses.cpp
+++ b/src/hotspot/share/classfile/javaClasses.cpp
@@ -1971,7 +1971,7 @@ void java_lang_VirtualThread::compute_offsets() {
 }
 
 bool java_lang_VirtualThread::is_instance(oop obj) {
-  return obj != nullptr && is_subclass(obj->klass());
+  return obj != nullptr && obj->is_a(vmClasses::BaseVirtualThread_klass());
 }
 
 oop java_lang_VirtualThread::carrier_thread(oop vthread) {


This change will crash on linux x86_32 when run the testcase ObjectMonitorUsage.java.

# V  [libjvm.so+0x833af1]  JvmtiEnvBase::get_threadOop_and_JavaThread(ThreadsList*, _jobject*, JavaThread**, oopDesc**)+0x121


[hs_err_pid233589.log](https://github.com/openjdk/jdk/files/15447775/hs_err_pid233589.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2132241354

From alanb at openjdk.org  Sun May 26 16:46:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 May 2024 16:46:00 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <-tbpkfcDNMlCE7lUDqrl2B_hKofsWED6q8ynzdyA62Q=.5f14044d-209e-4ac7-b019-47b8e597af70@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>
 <-tbpkfcDNMlCE7lUDqrl2B_hKofsWED6q8ynzdyA62Q=.5f14044d-209e-4ac7-b019-47b8e597af70@github.com>
Message-ID: <m1W7VsSeaS9jN-j_jnTKf0cARDFvvwKOKlN34VHaJTc=.d897066a-a9e0-4dd2-b74e-6d1bd82c5486@github.com>

On Sun, 26 May 2024 14:24:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> > That would mean it's not tested. I suspect the java_lang_VirtualThread::is_instance checks will need to be changed to test with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the alternative implementation.
> 
> Do you mean change like this:

No, I meant in JvmtiEnvBase::get_object_monitor_usage that you'll need to go through all places where it tests if the thread is a virtual thread, they will need to be changed to support the alternative implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2132281742

From syan at openjdk.org  Sun May 26 17:05:02 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 17:05:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <m1W7VsSeaS9jN-j_jnTKf0cARDFvvwKOKlN34VHaJTc=.d897066a-a9e0-4dd2-b74e-6d1bd82c5486@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>
 <-tbpkfcDNMlCE7lUDqrl2B_hKofsWED6q8ynzdyA62Q=.5f14044d-209e-4ac7-b019-47b8e597af70@github.com>
 <m1W7VsSeaS9jN-j_jnTKf0cARDFvvwKOKlN34VHaJTc=.d897066a-a9e0-4dd2-b74e-6d1bd82c5486@github.com>
Message-ID: <BKLaA8jN9s_gI6G_c2sr2_7HIduaEiVm3x6h8Sn-Qck=.c4f16bea-eeff-478c-b730-430792d38558@github.com>

On Sun, 26 May 2024 16:43:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > That would mean it's not tested. I suspect the java_lang_VirtualThread::is_instance checks will need to be changed to test with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the alternative implementation.
> > 
> > 
> > Do you mean change like this:
> 
> No, I meant in JvmtiEnvBase::get_object_monitor_usage that you'll need to go through all places where it tests if the thread is a virtual thread, they will need to be changed to support the alternative implementation.

Thanks, I will check it later.

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

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2132286758

From liach at openjdk.org  Sun May 26 19:21:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 May 2024 19:21:01 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java
In-Reply-To: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
References: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
Message-ID: <XzuFS6UyX4AQioLdcLCnAImdiVcFQzWu7Sw_9PGPPYA=.a13193b9-504c-40e5-9e8a-c7473829351c@github.com>

On Fri, 24 May 2024 18:11:18 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.
> 
> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.
> 
> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".
> 
> I am referring to line 69 in 
> `src/java.management/share/classes/javax/management/monitor/package-info.java`
> and lines 90 and 120 in 
> `src/java.management/share/classes/javax/management/remote/package-info.java`
> 
> Adding 2 dependencies just for 3 links didn't seem right.
> 
> edit: passes all tests, the failing test is a github actions issue

Now that markdown documentation is officially in JDK, are we considering to convert these files to markdown in package-info instead of the old `/** */` comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/19399#issuecomment-2132369715

From nbenalla at openjdk.org  Sun May 26 19:52:00 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 26 May 2024 19:52:00 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java
In-Reply-To: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
References: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
Message-ID: <AkjfOxe6YTqmP31fHP198nU7ifXr2xShb-Xfrz0gt7A=.4569b8e4-d859-41a1-92d1-1cf1ac99d46d@github.com>

On Fri, 24 May 2024 18:11:18 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.
> 
> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.
> 
> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".
> 
> I am referring to line 69 in 
> `src/java.management/share/classes/javax/management/monitor/package-info.java`
> and lines 90 and 120 in 
> `src/java.management/share/classes/javax/management/remote/package-info.java`
> 
> Adding 2 dependencies just for 3 links didn't seem right.
> 
> edit: passes all tests, the failing test is a github actions issue

I don't think that is a goal.

As for why I didn't use Markdown here, it would have made potentially backporting these changes more difficult.

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

PR Comment: https://git.openjdk.org/jdk/pull/19399#issuecomment-2132376943

From dholmes at openjdk.org  Mon May 27 02:35:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 May 2024 02:35:04 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
Message-ID: <PQqGn4wnr-Z_3RYaD3xPv7Vi4XUJzMkDUQ9W06gV_eo=.72d9af73-f69b-436f-8a9f-85a5511e699e@github.com>

On Sun, 26 May 2024 09:27:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. It should be predicated with `@requires vm.continuations` to be skipped.
> 
> Additional testing:
> - [x] linux x86_32, test has been skiped.
> - [x] linux x86_64, test still work.

Seems to me that test has been using virtual threads, ignoring the vm.continuations setting since before JDK-8328083 was fixed. It is not clear to me how the test was operating before-hand in that case? If it was running on 32-bit Linux without continuations before then skipping it now seems the wrong fix, as the updated test would seem to have some invalid constraints encoded in it.

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

PR Review: https://git.openjdk.org/jdk/pull/19405#pullrequestreview-2079895579

From nbenalla at openjdk.org  Mon May 27 09:01:48 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 27 May 2024 09:01:48 GMT
Subject: RFR: 8332070: Convert package.html files in `java.management` to
 package-info.java [v2]
In-Reply-To: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
References: <ld7tWRDEfC_ZydNriNQyha0-yTHRHciBsgqb-Q3NP6o=.5f632393-4dc4-4b08-9971-f4d57342809d@github.com>
Message-ID: <TDG0tTITmlnUkNwEmwwhXmvNE0gGkVvgLKe4OS1HQzU=.cc66eb58-1ed7-4eb5-b590-0ec77b9906df@github.com>

> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well.
> 
> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR.
> 
> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML.
> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require `<name>`".
> 
> I am referring to line 69 in 
> `src/java.management/share/classes/javax/management/monitor/package-info.java`
> and lines 90 and 120 in 
> `src/java.management/share/classes/javax/management/remote/package-info.java`
> 
> Adding 2 dependencies just for 3 links didn't seem right.
> 
> edit: passes all tests, the failing test is a github actions issue

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  better indentation - no content changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19399/files
  - new: https://git.openjdk.org/jdk/pull/19399/files/3bfc760d..c5d3147a

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

  Stats: 1141 lines in 8 files changed: 332 ins; 334 del; 475 mod
  Patch: https://git.openjdk.org/jdk/pull/19399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19399/head:pull/19399

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

From jwtang at openjdk.org  Mon May 27 09:51:06 2024
From: jwtang at openjdk.org (Jiawei Tang)
Date: Mon, 27 May 2024 09:51:06 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count
In-Reply-To: <BKLaA8jN9s_gI6G_c2sr2_7HIduaEiVm3x6h8Sn-Qck=.c4f16bea-eeff-478c-b730-430792d38558@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <J3MUdQLblSwXCZycvrSDtNupujQRhLhiCMIcMbReLNg=.bd526ffc-ae1c-4e2b-b7e4-3f605f1cff0c@github.com>
 <-tbpkfcDNMlCE7lUDqrl2B_hKofsWED6q8ynzdyA62Q=.5f14044d-209e-4ac7-b019-47b8e597af70@github.com>
 <m1W7VsSeaS9jN-j_jnTKf0cARDFvvwKOKlN34VHaJTc=.d897066a-a9e0-4dd2-b74e-6d1bd82c5486@github.com>
 <BKLaA8jN9s_gI6G_c2sr2_7HIduaEiVm3x6h8Sn-Qck=.c4f16bea-eeff-478c-b730-430792d38558@github.com>
Message-ID: <7KU8YitATgSV4CvpRc9kvn-V7dL6QLPHYAxIYp1AANE=.51cce574-bc41-4b4c-87ce-40f2f0b076ac@github.com>

On Sun, 26 May 2024 17:02:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> > > That would mean it's not tested. I suspect the java_lang_VirtualThread::is_instance checks will need to be changed to test with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the alternative implementation.
> > 
> > 
> > Do you mean change like this:
> 
> No, I meant in JvmtiEnvBase::get_object_monitor_usage that you'll need to go through all places where it tests if the thread is a virtual thread, they will need to be changed to support the alternative implementation.

Hi, using `is_a(vmClasses::BaseVirtualThread_klass()) ` only fix half failed results of this testcase. The `JvmtiEnvBase::get_object_monitor_usage` does not take the vthread into consideration when calculating nWant(mon->contentions()). I wonder if it needs to add some code like: 
```c++
    nWant = wantList->length();
    for(int i = 0; i < nWant; i++) {
      JavaThread* w = wantList->at(i);
      oop thread_oop = get_vthread_or_thread_oop(w);
      if (thread_oop->is_a(vmClasses::BaseVirtualThread_klass())) {
        nWant_Skip++;
      }
    }
    // ...
    ret.waiter_count = nWant - nWant_Skip;

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

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2133099822

From lmesnik at openjdk.org  Tue May 28 03:20:12 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 03:20:12 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't
 use finalization
Message-ID: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>

The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.

The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189

I verified that process is always already terminated when is cleaned during VM shutdown hook,
So the fix is just to remove the finalization.

I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.

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

Commit messages:
 - 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization

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

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

From syan at openjdk.org  Tue May 28 06:52:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 28 May 2024 06:52:13 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v2]
In-Reply-To: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
Message-ID: <BT875IZ_jkLxHPiGp238U62AiM-Wz5etterq5V6uOvE=.39ec49d4-7b70-4dd9-bae1-030b069011b2@github.com>

> Hi all,
>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. It should be predicated with `@requires vm.continuations` to be skipped.
> 
> Additional testing:
> - [x] linux x86_32, test has been skiped.
> - [x] linux x86_64, test still work.

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

  1. java_lang_VirtualThread::is_instance(thread_oop) -> thread_oop->is_a(vmClasses::BaseVirtualThread_klass()); 2. calculating nWant(mon->contentions())

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19405/files
  - new: https://git.openjdk.org/jdk/pull/19405/files/4a4326cc..ea28c232

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

  Stats: 14 lines in 2 files changed: 8 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19405/head:pull/19405

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

From kevinw at openjdk.org  Tue May 28 09:49:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 May 2024 09:49:06 GMT
Subject: RFR: 8332919: SA PointerLocation needs to print a newline after
 dumping java thread info for JNI Local Ref
In-Reply-To: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
References: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
Message-ID: <zlih8a-DhrqHc8JZO27ui-jOIJcg-O83VcScEbAOAec=.317449c8-e46c-479d-9cbf-5cac1233c305@github.com>

On Fri, 24 May 2024 20:03:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If PointerLocation discovers that an address is for a JNI local ref, it will print information about the thread that owns the JNI local ref. For JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on the call that says that it 'includes "\n"'. This is actually not true, and a separate println() is needed. I noticed this when using the clhsdb findpc command on a JNI local ref and noted that the next "hdsb> " prompt was printed at the end of the findpc output instead of on a new line.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19402#pullrequestreview-2082284417

From Alan.Bateman at oracle.com  Tue May 28 10:54:26 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 May 2024 11:54:26 +0100
Subject: JDK-8330846 - Status check
In-Reply-To: <CA+wBRWAJmArD_9UDN_rQGbYmj_hoe_zGcTc8h=gb1yUXO2v_Dg@mail.gmail.com>
References: <CA+wBRWAp4=FBXv=XsdE5spVK7hROH=hTd2RL1TTjkueRnbc5xg@mail.gmail.com>
 <CA+wBRWAJmArD_9UDN_rQGbYmj_hoe_zGcTc8h=gb1yUXO2v_Dg@mail.gmail.com>
Message-ID: <00b4ea11-57ed-4a22-9123-b3fc56d712ce@oracle.com>


I don't know if Alex Menkov is subscribed here, better to ask on 
serviceability-dev.

-Alan


On 28/05/2024 11:03, I?igo Mediavilla wrote:
>
>
> On Tue, May 28, 2024 at 11:28?AM I?igo Mediavilla <imediava at gmail.com> 
> wrote:
>
>     Hello,
>
>     I've been looking at possible tickets that I could work on under
>     the loom label in JBS, and I've run into : JDK-8330846 - Add
>     stacks of mounted virtual threads to the HotSpot thread dump
>
>     Link: https://bugs.openjdk.org/browse/JDK-8330846
>
>     It seems to be assigned to you, Alex Menkov. Is it something that
>     you're working on or that you'd want to work on, or would you be
>     OK if I took it ?
>
>     Regards
>
>     ??igo Mediavilla Saiz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240528/10884faa/attachment.htm>

From stuefe at openjdk.org  Tue May 28 13:40:27 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 May 2024 13:40:27 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
Message-ID: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>

In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.

It contains a workaround:


    // lazily create the single threaded resource area
    // pick a size which is not a standard since the pools don't exist yet
    _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);


It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.

This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.

---

Tests: GHAs.
I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

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

Commit messages:
 - copyrights
 - remove non_pool_size
 - start

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

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

From imediava at gmail.com  Tue May 28 14:17:04 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Tue, 28 May 2024 16:17:04 +0200
Subject: JDK-8330846 - Status check
Message-ID: <CA+wBRWAzJUbC=U=je+ZSh9UR97_XU1LwHL6tx81GwDagCj8GTw@mail.gmail.com>

Hello,

I'm redirecting this message here, that I posted in the beginning to the
loom-dev mailing list.

I've been looking at possible tickets that I could work on in JBS, and I've
run into : JDK-8330846 - Add stacks of mounted virtual threads to the
HotSpot thread dump

Link: https://bugs.openjdk.org/browse/JDK-8330846

It seems to be assigned to, Alex Menkov. Alex, is it something that you're
working on or that you'd want to work on, or would you be OK if I gave a it
a try ?

Regards

??igo Mediavilla Saiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240528/20f65b6b/attachment-0001.htm>

From stuefe at openjdk.org  Tue May 28 16:36:02 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 May 2024 16:36:02 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
Message-ID: <uSZOJdas-6i0qhqSXiPlzJBRo_AUENJtGpLteNmEgxw=.0923a8ba-d9cd-4cee-a735-96e40a40cd3b@github.com>

On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
> 
> It contains a workaround:
> 
> 
>     // lazily create the single threaded resource area
>     // pick a size which is not a standard since the pools don't exist yet
>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
> 
> 
> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
> 
> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
> 
> ---
> 
> Tests: GHAs.
> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

x86 problem unrelated

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

PR Comment: https://git.openjdk.org/jdk/pull/19425#issuecomment-2135680548

From alexey.menkov at oracle.com  Tue May 28 17:57:44 2024
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Tue, 28 May 2024 10:57:44 -0700
Subject: JDK-8330846 - Status check
In-Reply-To: <CA+wBRWAzJUbC=U=je+ZSh9UR97_XU1LwHL6tx81GwDagCj8GTw@mail.gmail.com>
References: <CA+wBRWAzJUbC=U=je+ZSh9UR97_XU1LwHL6tx81GwDagCj8GTw@mail.gmail.com>
Message-ID: <1919bcfb-53dd-4154-9f01-791460e722cc@oracle.com>

Hi,

I'm not started with the issue, feel free to take it.

--alex

On 28.05.2024 7:17, I?igo Mediavilla wrote:
> Hello,
> 
> I'm redirecting this message here, that I posted in the beginning to the 
> loom-dev mailing list.
> 
> I've been looking at possible tickets that I could work on in JBS, and 
> I've run into : JDK-8330846 - Add stacks of mounted virtual threads to 
> the HotSpot thread dump
> 
> Link: https://bugs.openjdk.org/browse/JDK-8330846 
> <https://bugs.openjdk.org/browse/JDK-8330846>
> 
> It seems to be assigned to, Alex Menkov. Alex, is it something that 
> you're working on or that you'd want to work on, or would you be OK if I 
> gave a it a try ?
> 
> Regards
> 
> ??igo Mediavilla Saiz

From stuefe at openjdk.org  Tue May 28 18:08:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 May 2024 18:08:03 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
Message-ID: <ocmtrC5BoDFEIjyqkmF0TaywU-J8MhzG9fz6OsTifqw=.458a7f95-5fc8-4194-ab36-018a2b480eb1@github.com>

On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
> 
> It contains a workaround:
> 
> 
>     // lazily create the single threaded resource area
>     // pick a size which is not a standard since the pools don't exist yet
>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
> 
> 
> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
> 
> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
> 
> ---
> 
> Tests: GHAs.
> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

@jdksjolen could you take a look? You know the Arena coding behind it, and this PR is, in a very circumvent way, one of the prerequisites for NMT simplifications I plan.

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

PR Comment: https://git.openjdk.org/jdk/pull/19425#issuecomment-2135835425

From cjplummer at openjdk.org  Tue May 28 19:09:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 May 2024 19:09:02 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization
In-Reply-To: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
Message-ID: <hoOtIS0OtaR7l5Jf5AVQ_U74drCSfv0EcEdyTg3KYJo=.49507dd7-bf48-4a14-94b9-92cc5a4ef435@github.com>

On Tue, 28 May 2024 03:15:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.
> 
> The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189
> 
> I verified that process is always already terminated when is cleaned during VM shutdown hook,
> So the fix is just to remove the finalization.
> 
> I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.

test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java line 221:

> 219:                 }
> 220: 
> 221:                 if (debuggee != null && debuggee.terminated()) {

Shouldn't this be `!debuggee.terminated()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19418#discussion_r1617771060

From lmesnik at openjdk.org  Tue May 28 20:28:12 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 20:28:12 GMT
Subject: RFR: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to don't
 use finalization
Message-ID: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>

The 
test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
uses cleanup() to kill debuggee process.

However, most tests kill the debuggee process explicitly. I verified that debuggee process is killed before test finishes. (Just by printing it's status.)

The fix adds a few checks debuggee.waitFor() int tests that didn't check debuggee process code.

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

Commit messages:
 - 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to don't use finalization

Changes: https://git.openjdk.org/jdk/pull/19437/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333108
  Stats: 42 lines in 6 files changed: 16 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19437/head:pull/19437

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

From lmesnik at openjdk.org  Tue May 28 20:55:30 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 20:55:30 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization [v2]
In-Reply-To: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
Message-ID: <5F7SNu0rI-N0JVsBFsFM9fa8DSv2EZEuTMjamZ7_9wE=.d71dd3d4-8fcf-44a6-a02a-2c49b7e08b6e@github.com>

> The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.
> 
> The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189
> 
> I verified that process is always already terminated when is cleaned during VM shutdown hook,
> So the fix is just to remove the finalization.
> 
> I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.

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

  fixed check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19418/files
  - new: https://git.openjdk.org/jdk/pull/19418/files/4f72b873..d77d6798

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

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

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

From lmesnik at openjdk.org  Tue May 28 20:55:30 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 20:55:30 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization [v2]
In-Reply-To: <hoOtIS0OtaR7l5Jf5AVQ_U74drCSfv0EcEdyTg3KYJo=.49507dd7-bf48-4a14-94b9-92cc5a4ef435@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
 <hoOtIS0OtaR7l5Jf5AVQ_U74drCSfv0EcEdyTg3KYJo=.49507dd7-bf48-4a14-94b9-92cc5a4ef435@github.com>
Message-ID: <B4YDTDEXjdVMkFT3A03eHU_HAfsP8xpCBFVjYVoWzyM=.ea4db405-6a52-42c6-94a9-fcbc73ec2561@github.com>

On Tue, 28 May 2024 19:05:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed check
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java line 221:
> 
>> 219:                 }
>> 220: 
>> 221:                 if (debuggee != null && debuggee.terminated()) {
> 
> Shouldn't this be `!debuggee.terminated()`?

Thanks for catching it! I've updated check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19418#discussion_r1617878786

From lmesnik at openjdk.org  Tue May 28 22:29:28 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 22:29:28 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v5]
In-Reply-To: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
Message-ID: <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>

> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
> 
> It happens when thread_name is set for tracing from jvmti functions.
> See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
> 
> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
> 
> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
> 
> Verified by running jvmti/jdi/jdb tests with tracing enabled.

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

 - fixed space.
 - The result is updated.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19275/files
  - new: https://git.openjdk.org/jdk/pull/19275/files/12ddfca2..81dc4073

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

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

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

From lmesnik at openjdk.org  Tue May 28 22:29:29 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 May 2024 22:29:29 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v4]
In-Reply-To: <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <xhOi9osSWWpj5DbaCkwOwYdq3DnasI5lHE2a3jotorg=.b1402a35-27c1-4ae4-a691-565bd07d75f5@github.com>
Message-ID: <UwJzvDKI8GmI5sccqRR5VbPjPNtWndW9NSVeD5n5b1s=.e7612952-730e-4f8f-9bb5-b742b13cfab3@github.com>

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong thread state

I discussed the issue with @sspitsyn and after this, I updated the function to return something more descriptive in case we can't read thread state. (Easier to understand what happens.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2136203620

From cjplummer at openjdk.org  Tue May 28 22:40:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 May 2024 22:40:04 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization [v2]
In-Reply-To: <5F7SNu0rI-N0JVsBFsFM9fa8DSv2EZEuTMjamZ7_9wE=.d71dd3d4-8fcf-44a6-a02a-2c49b7e08b6e@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
 <5F7SNu0rI-N0JVsBFsFM9fa8DSv2EZEuTMjamZ7_9wE=.d71dd3d4-8fcf-44a6-a02a-2c49b7e08b6e@github.com>
Message-ID: <UBsOTPp06c7Lyrl3oZuuXzagbvbW9uTOwrTC5oBFYlc=.2089b88a-f5c4-480f-ba65-babb1d1f26f4@github.com>

On Tue, 28 May 2024 20:55:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.
>> 
>> The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
>> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189
>> 
>> I verified that process is always already terminated when is cleaned during VM shutdown hook,
>> So the fix is just to remove the finalization.
>> 
>> I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed check

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19418#pullrequestreview-2083955546

From cjplummer at openjdk.org  Tue May 28 22:55:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 May 2024 22:55:02 GMT
Subject: RFR: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to
 don't use finalization
In-Reply-To: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
References: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
Message-ID: <BUMOTaEQOiNc8EajW6AUdqX3Rnhc-JWTzeHtW08eZLU=.fa990f55-514e-4ce0-babd-bc2522ed4a9c@github.com>

On Tue, 28 May 2024 20:24:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I verified that debuggee process is killed before test finishes. (Just by printing it's status.)

What about when the test fails?

test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001.java line 177:

> 175: 
> 176:         int code = debuggee.waitFor();
> 177:         if (code != 0) {

Why do the other tests check for Consts.JCK_STATUS_BASE, but here we check for 0?

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

PR Review: https://git.openjdk.org/jdk/pull/19437#pullrequestreview-2083968139
PR Review Comment: https://git.openjdk.org/jdk/pull/19437#discussion_r1617970400

From amenkov at openjdk.org  Tue May 28 23:07:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 28 May 2024 23:07:03 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v4]
In-Reply-To: <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
Message-ID: <BAaYLtsQga1T4ciWZgYjs49l-TNojPAQs3XglBlGBdY=.7496d299-c8de-43ab-9d57-795faf04dcd4@github.com>

On Fri, 3 May 2024 01:54:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update
>  - Revert "renamed current_thread to current"
>    
>    This reverts commit d5d614bcf0861466acd695296e974d2253f84c9f.
>  - Revert "renamed current_thread tp current"
>    
>    This reverts commit 4602632221044aa754a1bc8d11e7a3e9a0092590.

Ping. Can I get second review please.

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

PR Comment: https://git.openjdk.org/jdk/pull/18986#issuecomment-2136243867

From amenkov at openjdk.org  Tue May 28 23:07:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 28 May 2024 23:07:03 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <SJ8ZJR2hGyZyVshGWRD10QxrY1Mi2WiN08AAN50baqs=.ea084cbf-154d-49d7-b363-70428c4ebf2e@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

Ping. Can I get second review please.

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

PR Comment: https://git.openjdk.org/jdk/pull/18850#issuecomment-2136244148

From dholmes at openjdk.org  Tue May 28 23:13:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 May 2024 23:13:01 GMT
Subject: RFR: 8332919: SA PointerLocation needs to print a newline after
 dumping java thread info for JNI Local Ref
In-Reply-To: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
References: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
Message-ID: <tGp2DqhLSodSlrBTKCSceD20JcQbjD65rxIVyvC7dro=.e72315d1-ec44-4b5c-927e-ad8349f3a334@github.com>

On Fri, 24 May 2024 20:03:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If PointerLocation discovers that an address is for a JNI local ref, it will print information about the thread that owns the JNI local ref. For JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on the call that says that it 'includes "\n"'. This is actually not true, and a separate println() is needed. I noticed this when using the clhsdb findpc command on a JNI local ref and noted that the next "hdsb> " prompt was printed at the end of the findpc output instead of on a new line.

Trivially okay. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19402#pullrequestreview-2083983137

From cjplummer at openjdk.org  Tue May 28 23:25:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 May 2024 23:25:22 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject
Message-ID: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>

Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
- com/sun/jdi
- nsk/jdi
- nsk/jdwp
- nsk/jdb

-------------

Commit messages:
 - Update copyright
 - Unified 'worst case' comment.
 - Fix volatile issue with classObject() API.

Changes: https://git.openjdk.org/jdk/pull/19439/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328611
  Stats: 26 lines in 1 file changed: 2 ins; 13 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19439/head:pull/19439

PR: https://git.openjdk.org/jdk/pull/19439

From cjplummer at openjdk.org  Tue May 28 23:25:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 May 2024 23:25:22 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject
In-Reply-To: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
Message-ID: <glEnz5bclv-87AZHslFqgxt3wSv7Wa4ipIXfLxeCIJw=.5abc1e75-1269-47bf-b17b-f892165fd814@github.com>

On Tue, 28 May 2024 23:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
> - com/sun/jdi
> - nsk/jdi
> - nsk/jdwp
> - nsk/jdb

The bug is the classic "double-checked-locking" flaw. In general "double-checked-locking" does not work, but in this case, based on how it is used and the java memory model, it can be made to work by making the field volatile. Although the issue could be fixed by making the classObject field volatile, I decided to get rid of the double-checked-locking instead. There is little benefit to using it here (it simply avoids fetching the info twice when there is a race, which is very rare), and leaving it out simplifies the code and reduces overhead for the usual case (when there is no race). Regarding the pre-existing comment:

            // Are classObjects unique for an Object, or
            // created each time? Is this spec'ed?

Yes, they are unique. No they are not created each time. Probably this lack of understanding is why double-checked-locking was used here. The ObjectReference spec is a bit lose on the wording, referring to an ObjectReference as "An object that currently exists in the target VM". However, the implementation is not. VirtualMachineImpl.objectMirror() is used to create all ObjectReference instances, and it only creates one ObjectReference per JDWP objectID. I tested this by making classObject() fetch the ObjectReference on every call and compare the result to the cached value, and they always match. Also, the JDWP spec calls out that each java Object instance has 1 unique objectID. The following is the JDWP spec description of the objectID type.

"Uniquely identifies an object in the target VM. A particular object will be identified by exactly one objectID in JDWP commands and replies throughout its lifetime (or until the objectID is explicitly disposed). An ObjectID is not reused to identify a different object unless it has been explicitly disposed, regardless of whether the referenced object has been garbage collected. An objectID of 0 represents a null object. Note that the existence of an object ID does not prevent the garbage collection of the object. Any attempt to access a a garbage collected object with its object ID will result in the INVALID_OBJECT error code. Garbage collection can be disabled with the DisableCollection command, but it is not usually necessary to do so."

While looking into this bug I also ran across the similar classLoader() API, and noticed that it did not use synchronized and explained why in a comment. That is where I got the motivation to remove synchronized from classObject(). Then I found a bunch more similar APIs. I cleaned up their comment to be consistent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19439#issuecomment-2136257466

From sspitsyn at openjdk.org  Wed May 29 01:02:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 May 2024 01:02:45 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can
 lead to crashes
Message-ID: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>

Please, review the following `interp-only` issue related to carrier threads.
There are 3 problems fixed here:
 - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
 - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
 - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
 
 The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
 
 Testing:
 - Ran new test case locally
 - Ran mach5 tiers 1-6

-------------

Commit messages:
 - fix trailing spaces in new test
 - 8311177: Switching to interpreter only mode in carrier thread can lead to crashes

Changes: https://git.openjdk.org/jdk/pull/19438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311177
  Stats: 251 lines in 7 files changed: 231 ins; 9 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19438/head:pull/19438

PR: https://git.openjdk.org/jdk/pull/19438

From amenkov at openjdk.org  Wed May 29 01:13:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 29 May 2024 01:13:02 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject
In-Reply-To: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
Message-ID: <oJIHdzY0M-aegjsTV8KTvDYUpaVf9PG5Yp5w6dRQ1JU=.4e63f3d2-1faf-4a7a-bccd-7688d49393b6@github.com>

On Tue, 28 May 2024 23:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
> - com/sun/jdi
> - nsk/jdi
> - nsk/jdwp
> - nsk/jdb

Marked as reviewed by amenkov (Reviewer).

src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 185:

> 183:     public String signature() {
> 184:         if (signature == null) {
> 185:             // Does not need synchronization. Worst case is static info is fetched twice

Could you add dot at the end of all updated comments

-------------

PR Review: https://git.openjdk.org/jdk/pull/19439#pullrequestreview-2084073364
PR Review Comment: https://git.openjdk.org/jdk/pull/19439#discussion_r1618047117

From sspitsyn at openjdk.org  Wed May 29 01:23:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 May 2024 01:23:06 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v5]
In-Reply-To: <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>
Message-ID: <eGqo21pOUT7Ss8YBelw7WDHjsf99Q-9WjT871n61j88=.3985db73-a1ed-4f6e-b9d4-bd7bf655ef2d@github.com>

On Tue, 28 May 2024 22:29:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed space.
>  - The result is updated.

This looks good, Posted one nit though.

src/hotspot/share/prims/jvmtiTrace.cpp line 284:

> 282:     JavaThreadState current_state = JavaThread::cast(Thread::current())->thread_state();
> 283:     if (current_state == _thread_in_native || current_state == _thread_blocked) {
> 284:       return "not readable";

Nit: I'd suggest to make it more detailed, something like like this:
 "<non-readable thread name>" or "<NON-READABLE-THREAD-NAME>"

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19275#pullrequestreview-2084079674
PR Review Comment: https://git.openjdk.org/jdk/pull/19275#discussion_r1618051643

From amenkov at openjdk.org  Wed May 29 01:27:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 29 May 2024 01:27:03 GMT
Subject: RFR: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization [v2]
In-Reply-To: <5F7SNu0rI-N0JVsBFsFM9fa8DSv2EZEuTMjamZ7_9wE=.d71dd3d4-8fcf-44a6-a02a-2c49b7e08b6e@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
 <5F7SNu0rI-N0JVsBFsFM9fa8DSv2EZEuTMjamZ7_9wE=.d71dd3d4-8fcf-44a6-a02a-2c49b7e08b6e@github.com>
Message-ID: <dzPcFeTOIfrvv9GfGY21MSYot7GSbzHeTbKavyD7f60=.1680d41f-7972-4e6a-9285-99c8e3ca96c9@github.com>

On Tue, 28 May 2024 20:55:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.
>> 
>> The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
>> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189
>> 
>> I verified that process is always already terminated when is cleaned during VM shutdown hook,
>> So the fix is just to remove the finalization.
>> 
>> I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed check

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19418#pullrequestreview-2084083384

From cjplummer at openjdk.org  Wed May 29 01:47:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 01:47:27 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject [v2]
In-Reply-To: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
Message-ID: <Ql0yI6dsRk7hrOU4HHEJImvz70ZRpiqoc6k-68eeYk0=.fa5fda79-d2a0-4b2b-ac42-7b2590323cd4@github.com>

> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
> - com/sun/jdi
> - nsk/jdi
> - nsk/jdwp
> - nsk/jdb

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Add period at end of comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19439/files
  - new: https://git.openjdk.org/jdk/pull/19439/files/97376705..58295072

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19439&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19439&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19439/head:pull/19439

PR: https://git.openjdk.org/jdk/pull/19439

From cjplummer at openjdk.org  Wed May 29 01:47:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 01:47:27 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject [v2]
In-Reply-To: <oJIHdzY0M-aegjsTV8KTvDYUpaVf9PG5Yp5w6dRQ1JU=.4e63f3d2-1faf-4a7a-bccd-7688d49393b6@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
 <oJIHdzY0M-aegjsTV8KTvDYUpaVf9PG5Yp5w6dRQ1JU=.4e63f3d2-1faf-4a7a-bccd-7688d49393b6@github.com>
Message-ID: <CaRMJmz28xCrZCzJPXw2g2itFGuep3vTiX7dIV0pwzo=.3343cdfd-d386-41d6-8592-1f7eebed9025@github.com>

On Wed, 29 May 2024 01:09:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add period at end of comments
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 185:
> 
>> 183:     public String signature() {
>> 184:         if (signature == null) {
>> 185:             // Does not need synchronization. Worst case is static info is fetched twice
> 
> Could you add dot at the end of all updated comments

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19439#discussion_r1618065025

From cjplummer at openjdk.org  Wed May 29 01:51:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 01:51:06 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v4]
In-Reply-To: <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <N53WfYiaroQWvJ1krIyItoWjpcgG7b3DfENAokhTL2I=.bd4ae164-67a5-4935-9182-7f3caa4b6827@github.com>
Message-ID: <TcV9FCnwMFj6_h6nizuuwjutCcjukMphM0sbWZR-FiU=.88e35ace-3ade-4457-9922-609ad6e8bb86@github.com>

On Fri, 3 May 2024 01:54:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update
>  - Revert "renamed current_thread to current"
>    
>    This reverts commit d5d614bcf0861466acd695296e974d2253f84c9f.
>  - Revert "renamed current_thread tp current"
>    
>    This reverts commit 4602632221044aa754a1bc8d11e7a3e9a0092590.

Looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18986#pullrequestreview-2084100945

From cjplummer at openjdk.org  Wed May 29 02:06:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 02:06:02 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <Y5Y9ADzs1OxTfg1NpDcGTb93Mz7uvRgKbsdGraWGYiw=.997d7fcd-8291-4fbd-a67a-35884414006b@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

src/hotspot/share/services/heapDumper.cpp line 2137:

> 2135:   while ((cnt = segment_fs.read(_writer->buffer(), 1, _writer->buffer_size())) != 0) {
> 2136:     _writer->set_position(cnt);
> 2137:     _writer->flush();

Why flush on each iteration instead of just once after you are done with the loop?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18850#discussion_r1618079060

From yyang at openjdk.org  Wed May 29 02:55:06 2024
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 29 May 2024 02:55:06 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <0J2rH9D9iZyefwoFlYH2Zs0q_4YN-9lOn7tmH44AAXs=.00127363-c364-4010-8c46-e4911e9b5c54@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

I remember experimenting with different buffer sizes and figuring out that 4KB was the sweet spot. We could potentially switch to 1MB, but it would be better if we had some benchmark numbers to back that up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18850#issuecomment-2136422628

From jsjolen at openjdk.org  Wed May 29 07:45:02 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 29 May 2024 07:45:02 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
Message-ID: <Vo4Hf7qFLxuVdoyX9NbgAOSNwXqbK210UPf43lZ271E=.7b4978ea-26b3-4869-a9ec-89524d4efc47@github.com>

On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
> 
> It contains a workaround:
> 
> 
>     // lazily create the single threaded resource area
>     // pick a size which is not a standard since the pools don't exist yet
>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
> 
> 
> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
> 
> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
> 
> ---
> 
> Tests: GHAs.
> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

Today, the ChunkPools are allocated before main through static initialization. That means that the ChunkPools exists when main starts executing, so this is safe.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19425#pullrequestreview-2084558186

From mbaesken at openjdk.org  Wed May 29 09:14:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 May 2024 09:14:10 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
Message-ID: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>

When running with ubsan - enabled binaries (--enable-ubsan),
in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .

// null out memory for robustness
memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));

probably we should add checks there.
Example :
vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr

debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)

vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr

debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
debugee.stderr> #3 0x7f1e0a7eac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
debugee.stderr> #4 0x7f1e0a7ecc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
debugee.stderr> #5 0x7f1e0a7ed7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
debugee.stderr> #6 0x7f1e0a7ed8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
debugee.stderr> #7 0x7f1e0a57e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
debugee.stderr> #8 0x7f1e09bc4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
debugee.stderr> #9 0x7f1e0f9bf6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
debugee.stderr> #10 0x7f1e0ef1550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)

-------------

Commit messages:
 - JDK-8333149

Changes: https://git.openjdk.org/jdk/pull/19450/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19450&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333149
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19450/head:pull/19450

PR: https://git.openjdk.org/jdk/pull/19450

From sspitsyn at openjdk.org  Wed May 29 10:58:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 May 2024 10:58:02 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject [v2]
In-Reply-To: <Ql0yI6dsRk7hrOU4HHEJImvz70ZRpiqoc6k-68eeYk0=.fa5fda79-d2a0-4b2b-ac42-7b2590323cd4@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
 <Ql0yI6dsRk7hrOU4HHEJImvz70ZRpiqoc6k-68eeYk0=.fa5fda79-d2a0-4b2b-ac42-7b2590323cd4@github.com>
Message-ID: <b4uoTpht3p5dSaeGE1kNAITnuDSFnf9bjrqd9v2rkIU=.6af8a864-0990-4dd2-b8ee-b624ffd03526@github.com>

On Wed, 29 May 2024 01:47:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
>> - com/sun/jdi
>> - nsk/jdi
>> - nsk/jdwp
>> - nsk/jdb
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add period at end of comments

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19439#pullrequestreview-2085064312

From sspitsyn at openjdk.org  Wed May 29 11:02:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 May 2024 11:02:01 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
Message-ID: <mjJncpivFMkuXwPJ5oVMc0lMjsv-PiQsmjYei_4QhqQ=.f25c1b43-7931-42ee-b1f8-adf8d08f9dc6@github.com>

On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
> 
> It contains a workaround:
> 
> 
>     // lazily create the single threaded resource area
>     // pick a size which is not a standard since the pools don't exist yet
>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
> 
> 
> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
> 
> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
> 
> ---
> 
> Tests: GHAs.
> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19425#pullrequestreview-2085073625

From sspitsyn at openjdk.org  Wed May 29 11:18:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 May 2024 11:18:02 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <TrMOy-X4z20qEgfgt4us6cooP_Q3DZcgVpQKnxpHyCI=.24aecc9c-0764-427d-adce-a109e196eae3@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

Looks good. Thank you for taking care about it.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19450#pullrequestreview-2085104582

From mdoerr at openjdk.org  Wed May 29 12:24:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 May 2024 12:24:06 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <AAmxq85W4PI_pkZ0BZxARl66q8hjfKM36FMvHBYaFWM=.c7505e12-d5b8-4a9c-b335-c6adc530b977@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19450#pullrequestreview-2085244442

From mbaesken at openjdk.org  Wed May 29 12:41:06 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 May 2024 12:41:06 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <clZaYxtmYkzJT0QeQIRLYlBpe0_KI-klRbwfYwvIEYY=.62face3f-9ef7-4123-b2f2-2e9ac4da8423@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

Hi Martin and Serguei, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19450#issuecomment-2137313538

From mbaesken at openjdk.org  Wed May 29 12:41:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 May 2024 12:41:07 GMT
Subject: Integrated: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <F6snpdx26ssEAg6HFy_RkfEBjTThyj9yH1c443R3tCg=.c031ad7e-ab50-490f-8951-2eb869c8ae49@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

This pull request has now been integrated.

Changeset: 43a2f173
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43a2f17342af8f5bf1f5823df9fa0bf0bdfdfce2
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8333149: ubsan : memset on nullptr target detected in jvmtiEnvBase.cpp get_object_monitor_usage

Reviewed-by: sspitsyn, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/19450

From lmesnik at openjdk.org  Wed May 29 15:02:04 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 May 2024 15:02:04 GMT
Subject: RFR: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to
 don't use finalization
In-Reply-To: <BUMOTaEQOiNc8EajW6AUdqX3Rnhc-JWTzeHtW08eZLU=.fa990f55-514e-4ce0-babd-bc2522ed4a9c@github.com>
References: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
 <BUMOTaEQOiNc8EajW6AUdqX3Rnhc-JWTzeHtW08eZLU=.fa990f55-514e-4ce0-babd-bc2522ed4a9c@github.com>
Message-ID: <3sTPwxoOyDJ-Dv_SIZVNt3GTjdodmWrNM5U65c2Xggk=.72fd5317-c4a1-47ba-ba56-a5ecbbb0bbc2@github.com>

On Tue, 28 May 2024 22:51:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The 
>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
>> uses cleanup() to kill debuggee process.
>> 
>> However, most tests kill the debuggee process explicitly. I verified that debuggee process is killed before test finishes. (Just by printing it's status.)
>> 
>> The fix adds a few checks debuggee.waitFor() int tests that didn't check debuggee process code.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001.java line 177:
> 
>> 175: 
>> 176:         int code = debuggee.waitFor();
>> 177:         if (code != 0) {
> 
> Why do the other tests check for Consts.JCK_STATUS_BASE, but here we check for 0?

This is  a vm exit command test.
The test explicitly calls
'      vm.exit(0);' 
in line 157. So exit code is 0 and not "standard" 95.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19437#discussion_r1617975368

From lmesnik at openjdk.org  Wed May 29 15:02:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 May 2024 15:02:14 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v5]
In-Reply-To: <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>
Message-ID: <YKjhVRohJLZeQHjekhY5U9jVlLavHWBroFZCDDn_F2o=.b3c40c79-5240-40ac-9c92-9167cfc2d0b6@github.com>

On Tue, 28 May 2024 22:29:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>> 
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
>> 
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>> 
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
>> 
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed space.
>  - The result is updated.

The name becomes too long in the logs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19275#issuecomment-2137627742

From lmesnik at openjdk.org  Wed May 29 15:02:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 May 2024 15:02:14 GMT
Subject: Integrated: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state
In-Reply-To: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
Message-ID: <T2W7QQte0BqWvHgcfvIbaZa_hidD63O3H-E14LUUXaw=.47addce2-8fe3-446e-82a8-43492623c456@github.com>

On Fri, 17 May 2024 01:48:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
> 
> It happens when thread_name is set for tracing from jvmti functions.
> See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649 
> 
> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
> 
> The change should affect JVMTI trace mode only (-XX:TraceJVMTI). 
> 
> Verified by running jvmti/jdi/jdb tests with tracing enabled.

This pull request has now been integrated.

Changeset: 03b7a858
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03b7a8586a77983b1851ddd3f4555fe2fca57919
Stats:     17 lines in 2 files changed: 16 ins; 0 del; 1 mod

8332259: JvmtiTrace::safe_get_thread_name fails if current thread is in native state

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/19275

From lmesnik at openjdk.org  Wed May 29 15:04:11 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 May 2024 15:04:11 GMT
Subject: Integrated: 8333013: Update vmTestbase/nsk/share/LocalProcess.java to
 don't use finalization
In-Reply-To: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
References: <yAi518DE5y8d1yMFndkAP6DuCMhpof3_uEoBXUgkFRc=.efbc9db0-0023-402a-b14d-3c18d5ec4bd9@github.com>
Message-ID: <5aPNzk07OyHcIPFRO8OgWkOAMKLbyEEz0DZkA35CtPw=.bfa7cacd-6123-41d0-ba87-83e9c69ee419@github.com>

On Tue, 28 May 2024 03:15:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The vmTestbase/nsk/share/LocalProcess.java is a wrapper for debuggee process. It extends FinalizableObject to kill the debuggee process.
> 
> The debuggee process is used by nsk.jdb tests only, see runTest(...) in vmTestbase/nsk/share/jdb/JdbTest.java:
> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java#L189
> 
> I verified that process is always already terminated when is cleaned during VM shutdown hook,
> So the fix is just to remove the finalization.
> 
> I also moved LocalProcess into nsk.share.jdb to reduce the visibility of class and hardened checks in runTest.

This pull request has now been integrated.

Changeset: bc7d9e3d
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc7d9e3d0bc663bbbeb068889082da4a9f0fa8de
Stats:     343 lines in 3 files changed: 156 ins; 179 del; 8 mod

8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization

Reviewed-by: cjplummer, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/19418

From cjplummer at openjdk.org  Wed May 29 18:21:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 18:21:01 GMT
Subject: RFR: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to
 don't use finalization
In-Reply-To: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
References: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
Message-ID: <1sXb6CPAjnMMncdBAW6cIj7eJE37KtxVeyPVIBQF8HY=.94f1ce1d-5006-4716-9320-8a7418f3fad4@github.com>

On Tue, 28 May 2024 20:24:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
> uses cleanup() to kill debuggee process.
> 
> However, most tests kill the debuggee process explicitly. I verified that debuggee process is killed before test finishes. (Just by printing it's status.)
> 
> The fix adds a few checks debuggee.waitFor() int tests that didn't check debuggee process code.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19437#pullrequestreview-2086107795

From cjplummer at openjdk.org  Wed May 29 18:26:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 18:26:04 GMT
Subject: RFR: 8332919: SA PointerLocation needs to print a newline after
 dumping java thread info for JNI Local Ref
In-Reply-To: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
References: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
Message-ID: <I8yIgz-UNxNzdj4nssUXCgsg6OC2LWbVpnmbQcFiDHQ=.730a1e5b-9da5-4a69-a15b-ef874c96a322@github.com>

On Fri, 24 May 2024 20:03:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If PointerLocation discovers that an address is for a JNI local ref, it will print information about the thread that owns the JNI local ref. For JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on the call that says that it 'includes "\n"'. This is actually not true, and a separate println() is needed. I noticed this when using the clhsdb findpc command on a JNI local ref and noted that the next "hdsb> " prompt was printed at the end of the findpc output instead of on a new line.

Thank you for the reviews Kevin and David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19402#issuecomment-2138012861

From cjplummer at openjdk.org  Wed May 29 18:26:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 18:26:05 GMT
Subject: Integrated: 8332919: SA PointerLocation needs to print a newline after
 dumping java thread info for JNI Local Ref
In-Reply-To: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
References: <sU6NaKnEOoBgKbkkheaGsyHJESmH6G-UzEYcOOGP7YQ=.936eb78a-1d6a-41ad-b536-cb89e3f447ee@github.com>
Message-ID: <qmSY9UwVrYx9q8-rCpNALTx9dXpm3z6NUwhCUGo4HQc=.bf7eb473-0045-45b6-8437-cd211c5e8c16@github.com>

On Fri, 24 May 2024 20:03:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If PointerLocation discovers that an address is for a JNI local ref, it will print information about the thread that owns the JNI local ref. For JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on the call that says that it 'includes "\n"'. This is actually not true, and a separate println() is needed. I noticed this when using the clhsdb findpc command on a JNI local ref and noted that the next "hdsb> " prompt was printed at the end of the findpc output instead of on a new line.

This pull request has now been integrated.

Changeset: c8eea59f
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8eea59f508158075382079316cf0990116ff98e
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8332919: SA PointerLocation needs to print a newline after dumping java thread info for JNI Local Ref

Reviewed-by: kevinw, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/19402

From cjplummer at openjdk.org  Wed May 29 19:11:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 19:11:03 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes
In-Reply-To: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
Message-ID: <GcoOAAJI3pWK-G8dN8HfVCP1pyuzF109tRaB-szBOjk=.5495536a-30ad-4671-b712-5304294a13c3@github.com>

On Tue, 28 May 2024 22:24:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>  
>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>  
>  Testing:
>  - Ran new test case locally
>  - Ran mach5 tiers 1-6

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 201:

> 199: 
> 200:   // need to reset this value after the breakpoint_hit1
> 201:   received_method_exit_event = JNI_FALSE;

There was a loom-dev email thread regarding this last year. Seems related. I had concluded that the way the test was written that no MethodExit event should have been received. I'm not sure if I missed something in my analysis or if this failure is a result of your changes:

https://mail.openjdk.org/pipermail/loom-dev/2023-August/006059.html
https://mail.openjdk.org/pipermail/loom-dev/2023-September/006170.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619356206

From cjplummer at openjdk.org  Wed May 29 20:22:12 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 May 2024 20:22:12 GMT
Subject: RFR: 8332751: Broken link in VirtualMachine.html
Message-ID: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>

Fixed broken javadoc link. I confirmed that it currently is broken as can be seen in the JDK 22 javadocs:

https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()

Click on the "virtual threads" link within the allThreads() description to see the broken link. 

I verified the fix by building the javadocs and checking that the link now works.

-------------

Commit messages:
 - Fix broken link

Changes: https://git.openjdk.org/jdk/pull/19469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332751
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19469/head:pull/19469

PR: https://git.openjdk.org/jdk/pull/19469

From amenkov at openjdk.org  Wed May 29 20:52:01 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 29 May 2024 20:52:01 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <0J2rH9D9iZyefwoFlYH2Zs0q_4YN-9lOn7tmH44AAXs=.00127363-c364-4010-8c46-e4911e9b5c54@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
 <0J2rH9D9iZyefwoFlYH2Zs0q_4YN-9lOn7tmH44AAXs=.00127363-c364-4010-8c46-e4911e9b5c54@github.com>
Message-ID: <EftI2ZRRSgse2dJ7uEd1E4cSu6VJmgMIR31R77IQCzw=.228ccc09-526e-41be-9f3b-5fbd90195e71@github.com>

On Wed, 29 May 2024 02:52:22 GMT, Yi Yang <yyang at openjdk.org> wrote:

> I remember experimenting with different buffer sizes and figuring out that 4KB was the sweet spot. We could potentially switch to 1MB, but it would be better if we had some benchmark numbers to back that up.

My experiments shown that with the fix time of the merge decreased ~5%. 
But this is not just change of the buffer size:
Before the fix merger (1) read `segment_fs` in 4K chunks, (2) wrote them (copying memory) to `_writer->_buffer` until the buffer is full (i.e. 256 read iterations) and then (3) flush `_writer->_buffer`;
With the fix (1) and (2) are replaced with single reading of 1MB directly to `_writer->_buffer` (no memory copy).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18850#issuecomment-2138238839

From amenkov at openjdk.org  Wed May 29 20:52:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 29 May 2024 20:52:02 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <Y5Y9ADzs1OxTfg1NpDcGTb93Mz7uvRgKbsdGraWGYiw=.997d7fcd-8291-4fbd-a67a-35884414006b@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
 <Y5Y9ADzs1OxTfg1NpDcGTb93Mz7uvRgKbsdGraWGYiw=.997d7fcd-8291-4fbd-a67a-35884414006b@github.com>
Message-ID: <DRedSFcsDGDXRbSG3G7yqGvSVJOmRwVnqaTu-4UNOMU=.f86f24b9-580f-4465-b074-b98dd9090230@github.com>

On Wed, 29 May 2024 02:03:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
>> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
>> 
>> Testing: all HeapDump-related tests on Oracle supported platforms
>
> src/hotspot/share/services/heapDumper.cpp line 2137:
> 
>> 2135:   while ((cnt = segment_fs.read(_writer->buffer(), 1, _writer->buffer_size())) != 0) {
>> 2136:     _writer->set_position(cnt);
>> 2137:     _writer->flush();
> 
> Why flush on each iteration instead of just once after you are done with the loop?

Standard way to use AbstractDumpWriter is to use `AbstractDumpWriter::write_XXX` methods (they all call `write_raw(const void* s, size_t len)` which copies data from the provided memory to `_writer->buffer()`, and flushes when the buffer is full)
This code uses writer internals - on each iteration we read up to 1MB from `segment_fs` directly to `_writer->buffer()`, so we need to flush it before performing next read, otherwise data in the buffer will be overridden.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18850#discussion_r1619412072

From sspitsyn at openjdk.org  Thu May 30 00:21:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 00:21:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v2]
In-Reply-To: <BT875IZ_jkLxHPiGp238U62AiM-Wz5etterq5V6uOvE=.39ec49d4-7b70-4dd9-bae1-030b069011b2@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BT875IZ_jkLxHPiGp238U62AiM-Wz5etterq5V6uOvE=.39ec49d4-7b70-4dd9-bae1-030b069011b2@github.com>
Message-ID: <qq4oHd9DU8f73MPStE3ZO3E-qZrBfksxKHlv4r1WUis=.a80238b3-563d-4030-bde8-0f4ba4d1a7bb@github.com>

On Tue, 28 May 2024 06:52:13 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>>   There are two changes in this PR:
>> 1. In JvmtiEnvBase::get_object_monitor_usage function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation.
>> 2. The JvmtiEnvBase::get_object_monitor_usage does take the vthread into consideration when calculating nWant(mon->contentions()).
>> 
>>   
>> 
>> Additional testing:
>> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140)
>> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed.
>> 
>> [x64.log](https://github.com/openjdk/jdk/files/15480081/x64.log)
>> [x86.log](https://github.com/openjdk/jdk/files/15480083/x86.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. java_lang_VirtualThread::is_instance(thread_oop) -> thread_oop->is_a(vmClasses::BaseVirtualThread_klass()); 2. calculating nWant(mon->contentions())

The fix looks good in general but I've inlined one suggestion.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1524:

> 1522:         nWant_Skip++;
> 1523:       }
> 1524:     }

Thank you for taking care about this issue.
The nWant_Skip and and the fragment with lines 1518-1524 would not be needed if the function `Threads::get_pending_threads()` is fixed instead:

-    if (java_lang_VirtualThread::is_instance(thread_oop)) {
+    if (thread_oop->is_a(vmClasses::BaseVirtualThread_klass())) {
``

-------------

PR Review: https://git.openjdk.org/jdk/pull/19405#pullrequestreview-2086876665
PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1619620594

From amenkov at openjdk.org  Thu May 30 00:32:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 30 May 2024 00:32:04 GMT
Subject: RFR: 8332751: Broken link in VirtualMachine.html
In-Reply-To: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
References: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
Message-ID: <pGrIB_hw_vM-EEd_rY1scouIU8bE-WjSxH5T0zmbRJg=.374505da-bea4-43f0-93bb-bafce9b55d9b@github.com>

On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed broken javadoc link. I confirmed that it currently is broken as can be seen in the JDK 22 javadocs:
> 
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
> 
> Click on the "virtual threads" link within the allThreads() description to see the broken link. 
> 
> I verified the fix by building the javadocs and checking that the link now works.

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19469#pullrequestreview-2086884777

From amenkov at openjdk.org  Thu May 30 01:09:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 30 May 2024 01:09:03 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes
In-Reply-To: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
Message-ID: <gly3DX1LulyX609FsUylF5TFuX-hUPp6gqnYKInzNJw=.8105dfbc-3431-40d3-9f4d-5fb9a099db7d@github.com>

On Tue, 28 May 2024 22:24:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>  
>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>  
>  Testing:
>  - Ran new test case locally
>  - Ran mach5 tiers 1-6

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/CarrierThreadEventNotification.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

(c) 2024

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

(c) 2024

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 40:

> 38: 
> 39: static const char* CTHREAD_NAME_START = "ForkJoinPool";
> 40: static const int CTHREAD_NAME_START_LEN = (int)strlen("ForkJoinPool");

should be `size_t` (the value is used for `strncmp` which expects `size_t`)

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 44:

> 42: static jint
> 43: get_cthreads(JNIEnv* jni, jthread** cthreads_p) {
> 44:   jthread* tested_cthreads = NULL;

Suggestion:

  jthread* tested_cthreads = nullptr;

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 44:

> 42: static jint
> 43: get_cthreads(JNIEnv* jni, jthread** cthreads_p) {
> 44:   jthread* tested_cthreads = NULL;

This local variable has the same name as global.
I'd suggest to rename the local var or remove it (and the function should set both `tested_cthreads` and ` cthread_cnt`)

test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 91:

> 89:     for (int i = 0; i < cthread_cnt; i++) {
> 90:       jthread thread = tested_cthreads[i];
> 91:       char* tname = get_thread_name(jvmti, jni, thread);

`tname` is not needed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619642814
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619642981
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619643931
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619660102
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619662506
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619665290

From syan at openjdk.org  Thu May 30 01:13:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 May 2024 01:13:20 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
Message-ID: <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>

> Hi all,
>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>   There are two changes in this PR:
> 1. In JvmtiEnvBase::get_object_monitor_usage function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation.
> 2. The JvmtiEnvBase::get_object_monitor_usage does take the vthread into consideration when calculating nWant(mon->contentions()).
> 
>   
> 
> Additional testing:
> - [ ] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140)
> - [ ] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed.
> 
> [x64.log](https://github.com/openjdk/jdk/files/15480081/x64.log)
> [x86.log](https://github.com/openjdk/jdk/files/15480083/x86.log)

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19405/files
  - new: https://git.openjdk.org/jdk/pull/19405/files/ea28c232..83521f47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19405&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19405&range=01-02

  Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19405/head:pull/19405

PR: https://git.openjdk.org/jdk/pull/19405

From syan at openjdk.org  Thu May 30 01:13:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 May 2024 01:13:20 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v2]
In-Reply-To: <qq4oHd9DU8f73MPStE3ZO3E-qZrBfksxKHlv4r1WUis=.a80238b3-563d-4030-bde8-0f4ba4d1a7bb@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BT875IZ_jkLxHPiGp238U62AiM-Wz5etterq5V6uOvE=.39ec49d4-7b70-4dd9-bae1-030b069011b2@github.com>
 <qq4oHd9DU8f73MPStE3ZO3E-qZrBfksxKHlv4r1WUis=.a80238b3-563d-4030-bde8-0f4ba4d1a7bb@github.com>
Message-ID: <65bJe4ej1j7pmlIboOUqO4DMgp-2Uxw94pp0Stagcw0=.e86cd27f-2960-4a86-bdc2-8174c283f232@github.com>

On Thu, 30 May 2024 00:17:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. java_lang_VirtualThread::is_instance(thread_oop) -> thread_oop->is_a(vmClasses::BaseVirtualThread_klass()); 2. calculating nWant(mon->contentions())
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1524:
> 
>> 1522:         nWant_Skip++;
>> 1523:       }
>> 1524:     }
> 
> Thank you for taking care about this issue.
> The nWant_Skip and and the fragment with lines 1518-1524 would not be needed if the function `Threads::get_pending_threads()` is fixed instead:
> 
> -    if (java_lang_VirtualThread::is_instance(thread_oop)) {
> +    if (thread_oop->is_a(vmClasses::BaseVirtualThread_klass())) {
> ``

Thank you for your correction. The code has been updated accordingly your suggest. I need redo the additional testing to verify it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1619669502

From syan at openjdk.org  Thu May 30 01:22:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 May 2024 01:22:11 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v2]
In-Reply-To: <qq4oHd9DU8f73MPStE3ZO3E-qZrBfksxKHlv4r1WUis=.a80238b3-563d-4030-bde8-0f4ba4d1a7bb@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BT875IZ_jkLxHPiGp238U62AiM-Wz5etterq5V6uOvE=.39ec49d4-7b70-4dd9-bae1-030b069011b2@github.com>
 <qq4oHd9DU8f73MPStE3ZO3E-qZrBfksxKHlv4r1WUis=.a80238b3-563d-4030-bde8-0f4ba4d1a7bb@github.com>
Message-ID: <ASoOpxukLcQG9EFyV_pgkW6vWisf3E2muz6ZzlP2Ui0=.ae9ded52-9339-42dd-b334-166ee0cf30b9@github.com>

On Thu, 30 May 2024 00:18:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks good in general but I've inlined one suggestion.

Thank you for your correction. The code has been updated accordingly your suggest. I need redo the additional testing to verify it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2138500393

From yyang at openjdk.org  Thu May 30 01:38:03 2024
From: yyang at openjdk.org (Yi Yang)
Date: Thu, 30 May 2024 01:38:03 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <UXYtGIsfdBHdZ7DtSJXCZJqTGsiUtQR-kIoEwqxe7rs=.3a0470de-24b0-4bbc-ae1c-7f23f0e7e10a@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

Thanks for the explanation, looks good then~

-------------

Marked as reviewed by yyang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18850#pullrequestreview-2086936328

From sspitsyn at openjdk.org  Thu May 30 02:04:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 02:04:02 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes
In-Reply-To: <gly3DX1LulyX609FsUylF5TFuX-hUPp6gqnYKInzNJw=.8105dfbc-3431-40d3-9f4d-5fb9a099db7d@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
 <gly3DX1LulyX609FsUylF5TFuX-hUPp6gqnYKInzNJw=.8105dfbc-3431-40d3-9f4d-5fb9a099db7d@github.com>
Message-ID: <w-eTc_rMP8cdHXyGTgxlo8o8JF4kbWhd4R6Xbix64t8=.d34a77b5-a435-4834-b5c2-81a9c7bb942d@github.com>

On Thu, 30 May 2024 00:41:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>>  
>>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>>  
>>  Testing:
>>  - Ran new test case locally
>>  - Ran mach5 tiers 1-6
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/CarrierThreadEventNotification.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> (c) 2024

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> (c) 2024

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 40:
> 
>> 38: 
>> 39: static const char* CTHREAD_NAME_START = "ForkJoinPool";
>> 40: static const int CTHREAD_NAME_START_LEN = (int)strlen("ForkJoinPool");
> 
> should be `size_t` (the value is used for `strncmp` which expects `size_t`)

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 44:
> 
>> 42: static jint
>> 43: get_cthreads(JNIEnv* jni, jthread** cthreads_p) {
>> 44:   jthread* tested_cthreads = NULL;
> 
> Suggestion:
> 
>   jthread* tested_cthreads = nullptr;

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619716426
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619716604
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619717881
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619718490

From dholmes at openjdk.org  Thu May 30 02:08:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 May 2024 02:08:10 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <clZaYxtmYkzJT0QeQIRLYlBpe0_KI-klRbwfYwvIEYY=.62face3f-9ef7-4123-b2f2-2e9ac4da8423@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
 <clZaYxtmYkzJT0QeQIRLYlBpe0_KI-klRbwfYwvIEYY=.62face3f-9ef7-4123-b2f2-2e9ac4da8423@github.com>
Message-ID: <8u0gQV87R2tRvHGmuMB94iM8VR9bIC3t_acofhGNG1E=.8bc0312d-7c87-4e38-891c-ca1f3034a4c7@github.com>

On Wed, 29 May 2024 12:38:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running with ubsan - enabled binaries (--enable-ubsan),
>> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
>> 
>> // null out memory for robustness
>> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
>> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
>> 
>> probably we should add checks there.
>> Example :
>> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
>> 
>> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
>> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
>> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
>> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
>> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
>> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
>> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
>> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
>> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
>> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
>> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
>> 
>> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
>> 
>> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
>> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
>> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
>> debugee.std...
>
> Hi Martin and Serguei, thanks for the reviews !

@MBaesken  This was not proposed as a trivial PR and so is subject to the 24 hour rule. Please don't push these ubsan "fixes" quickly as we need time to assess their validity and the right way to address them.

This fix looks wrong to me because those values cannot be null as it implies the `allocate` function failed which means we would not reach this code!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19450#issuecomment-2138540409

From sspitsyn at openjdk.org  Thu May 30 02:13:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 02:13:01 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes
In-Reply-To: <gly3DX1LulyX609FsUylF5TFuX-hUPp6gqnYKInzNJw=.8105dfbc-3431-40d3-9f4d-5fb9a099db7d@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
 <gly3DX1LulyX609FsUylF5TFuX-hUPp6gqnYKInzNJw=.8105dfbc-3431-40d3-9f4d-5fb9a099db7d@github.com>
Message-ID: <NgO5_9Xbpvma1_criLn9VRjwTmcptlRp_ISbeYNy_AU=.654fd69f-b69e-4c07-b671-9422f3201bc7@github.com>

On Thu, 30 May 2024 01:03:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>>  
>>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>>  
>>  Testing:
>>  - Ran new test case locally
>>  - Ran mach5 tiers 1-6
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 44:
> 
>> 42: static jint
>> 43: get_cthreads(JNIEnv* jni, jthread** cthreads_p) {
>> 44:   jthread* tested_cthreads = NULL;
> 
> This local variable has the same name as global.
> I'd suggest to rename the local var or remove it (and the function should set both `tested_cthreads` and ` cthread_cnt`)

Thanks. Renamed the local to `cthreads` and the global to `carrier_threads`.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 91:
> 
>> 89:     for (int i = 0; i < cthread_cnt; i++) {
>> 90:       jthread thread = tested_cthreads[i];
>> 91:       char* tname = get_thread_name(jvmti, jni, thread);
> 
> `tname` is not needed

Removed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619726804
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619728368

From sspitsyn at openjdk.org  Thu May 30 02:31:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 02:31:29 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes [v2]
In-Reply-To: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
Message-ID: <55rWd_Kn3Jf8kfmkMtVnzRVs_o0KK_jnuZthiS9awDA=.555b5928-38d1-422c-9014-7d4cf31a950d@github.com>

> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>  
>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>  
>  Testing:
>  - Ran new test case locally
>  - Ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed nits in new test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19438/files
  - new: https://git.openjdk.org/jdk/pull/19438/files/a0f5d278..2f75975f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=00-01

  Stats: 18 lines in 2 files changed: 0 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19438/head:pull/19438

PR: https://git.openjdk.org/jdk/pull/19438

From sspitsyn at openjdk.org  Thu May 30 02:44:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 02:44:06 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes [v2]
In-Reply-To: <GcoOAAJI3pWK-G8dN8HfVCP1pyuzF109tRaB-szBOjk=.5495536a-30ad-4671-b712-5304294a13c3@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
 <GcoOAAJI3pWK-G8dN8HfVCP1pyuzF109tRaB-szBOjk=.5495536a-30ad-4671-b712-5304294a13c3@github.com>
Message-ID: <7D1Cchdl8jpFGHWJq0YLCELHQGXz6OLpkxHdLahhgmA=.4b815259-ba39-4ecb-9819-585c0123fca5@github.com>

On Wed, 29 May 2024 19:06:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed nits in new test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 201:
> 
>> 199: 
>> 200:   // need to reset this value after the breakpoint_hit1
>> 201:   received_method_exit_event = JNI_FALSE;
> 
> There was a loom-dev email thread regarding this last year. Seems related. I had concluded that the way the test was written that no MethodExit event should have been received. I'm not sure if I missed something in my analysis or if this failure is a result of your changes:
> 
> https://mail.openjdk.org/pipermail/loom-dev/2023-August/006059.html
> https://mail.openjdk.org/pipermail/loom-dev/2023-September/006170.html

Thank you for the comment and links to the discussion. In fact, I've observed the MethodExit events really posted between the breakpoint hits: `hit1` and `hit2`. The first one is at the return from the `unmount()` method. I was not able to prove why they should not be expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619756552

From dholmes at openjdk.org  Thu May 30 06:06:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 May 2024 06:06:09 GMT
Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current
 thread is in native state [v5]
In-Reply-To: <eGqo21pOUT7Ss8YBelw7WDHjsf99Q-9WjT871n61j88=.3985db73-a1ed-4f6e-b9d4-bd7bf655ef2d@github.com>
References: <L2duvbuudso4CDxJq4M2xR1TlLi46gQwCraa9WDAxqs=.ca50daaf-1c5f-4a52-9b16-f08a3b4fd173@github.com>
 <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com>
 <eGqo21pOUT7Ss8YBelw7WDHjsf99Q-9WjT871n61j88=.3985db73-a1ed-4f6e-b9d4-bd7bf655ef2d@github.com>
Message-ID: <wR1uw60PqA9CZwJ2wV5CYnYc2eCDA12tU86UiurxYDc=.769d3456-5abc-456f-aeaa-60798aeb2b1f@github.com>

On Wed, 29 May 2024 01:18:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed space.
>>  - The result is updated.
>
> src/hotspot/share/prims/jvmtiTrace.cpp line 284:
> 
>> 282:     JavaThreadState current_state = JavaThread::cast(Thread::current())->thread_state();
>> 283:     if (current_state == _thread_in_native || current_state == _thread_blocked) {
>> 284:       return "not readable";
> 
> Nit: I'd suggest to make it more detailed, something like like this:
>  "<non-readable thread name>" or "<NON-READABLE-THREAD-NAME>"

Yes this would have looked better if the text was more clearly an error message with angle brackets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19275#discussion_r1619989123

From alanb at openjdk.org  Thu May 30 06:12:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 06:12:03 GMT
Subject: RFR: 8332751: Broken link in VirtualMachine.html
In-Reply-To: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
References: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
Message-ID: <UmaPoJ72xzs8tXuiv4BESb2G3_JaBoF2oacUM7wZ4Rg=.a7d59ff8-f73d-4bf5-be53-c4d301b3ab50@github.com>

On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed broken javadoc link. I confirmed that it currently is broken as can be seen in the JDK 22 javadocs:
> 
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
> 
> Click on the "virtual threads" link within the allThreads() description to see the broken link. 
> 
> I verified the fix by building the javadocs and checking that the link now works.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19469#pullrequestreview-2087310583

From dholmes at openjdk.org  Thu May 30 06:17:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 May 2024 06:17:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
Message-ID: <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>

On Thu, 30 May 2024 01:13:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>>   There are two changes in this PR:
>> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation.
>> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low.
>> 
>>   
>> 
>> Additional testing:
>> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140)
>> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1486:

> 1484:   if (owning_thread != nullptr) {
> 1485:     oop thread_oop = get_vthread_or_thread_oop(owning_thread);
> 1486:     bool is_virtual = thread_oop->is_a(vmClasses::BaseVirtualThread_klass());

It strikes me that this should be handled by `java_lang_VirtualThread::is_instance` based on whether there is continuation support or not. External code like this should not, IMO, needed to know about `BaseVirtualThread`. @AlanBateman  what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1620005105

From alanb at openjdk.org  Thu May 30 06:34:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 06:34:06 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
 <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>
Message-ID: <MLW8diuS18ZU2uDvEX1PisTd1zLs0pg7vYaku-sXaLs=.f511f704-af2f-464f-8d50-69ccdeeb5edb@github.com>

On Thu, 30 May 2024 06:14:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1486:
> 
>> 1484:   if (owning_thread != nullptr) {
>> 1485:     oop thread_oop = get_vthread_or_thread_oop(owning_thread);
>> 1486:     bool is_virtual = thread_oop->is_a(vmClasses::BaseVirtualThread_klass());
> 
> It strikes me that this should be handled by `java_lang_VirtualThread::is_instance` based on whether there is continuation support or not. External code like this should not, IMO, needed to know about `BaseVirtualThread`. @AlanBateman  what do you think?

Hopefully the ports will catch up someday and the alternative implementation can be removed. 

We decided not to rename java.lang.VirtualThread when introducing the alternative implementation as it's just too disruptive. The super class that both implementations extend is BaseVirtualThread so testing for an instance of that is correct for the two implementations.

If it helps the readability then introducing a function to test if a thread is a virtual thread might help. It could use VMContinuations if needed but right now, testing for an instanceof BaseVirtualThread is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1620033427

From syan at openjdk.org  Thu May 30 06:39:02 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 May 2024 06:39:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
Message-ID: <TvJGm5rM65eCaKsEXeHiThcNnTdBathC-5pfDoOl1zA=.86ca0deb-a475-4e0e-aad8-0885be131d8f@github.com>

On Thu, 30 May 2024 01:13:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>>   There are two changes in this PR:
>> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation.
>> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low.
>> 
>>   
>> 
>> Additional testing:
>> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140)
>> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()

The GHA test runner report a intermittent failure, which has been recorded in [JDK-8287078](https://bugs.openjdk.org/browse/JDK-8287078), I think it's unrelated to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2138784734

From dholmes at openjdk.org  Thu May 30 06:54:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 May 2024 06:54:08 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <MLW8diuS18ZU2uDvEX1PisTd1zLs0pg7vYaku-sXaLs=.f511f704-af2f-464f-8d50-69ccdeeb5edb@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
 <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>
 <MLW8diuS18ZU2uDvEX1PisTd1zLs0pg7vYaku-sXaLs=.f511f704-af2f-464f-8d50-69ccdeeb5edb@github.com>
Message-ID: <vieLBomJBOv_vKe2DKKhaRNPX8QGvVtsKduHWPl9dFw=.bd73bf25-1158-4ded-9b13-f5a6f70e6227@github.com>

On Thu, 30 May 2024 06:31:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1486:
>> 
>>> 1484:   if (owning_thread != nullptr) {
>>> 1485:     oop thread_oop = get_vthread_or_thread_oop(owning_thread);
>>> 1486:     bool is_virtual = thread_oop->is_a(vmClasses::BaseVirtualThread_klass());
>> 
>> It strikes me that this should be handled by `java_lang_VirtualThread::is_instance` based on whether there is continuation support or not. External code like this should not, IMO, needed to know about `BaseVirtualThread`. @AlanBateman  what do you think?
>
> Hopefully the ports will catch up someday and the alternative implementation can be removed. 
> 
> We decided not to rename java.lang.VirtualThread when introducing the alternative implementation as it's just too disruptive. The super class that both implementations extend is BaseVirtualThread so testing for an instance of that is correct for the two implementations.
> 
> If it helps the readability then introducing a function to test if a thread is a virtual thread might help. It could use VMContinuations if needed but right now, testing for an instanceof BaseVirtualThread is okay.

Okay. I still think that should be hidden behind the `java_lang_VirtualThread::is_instance` as it is an implementation detail the JVMTI and thread code shouldn't need to know about IMO. Once the alternative implementation is removed I expect these explicit checks for `BaseVirtualThread` will need to be reverted and we could avoid that if we make a change now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1620065937

From alanb at openjdk.org  Thu May 30 07:17:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 07:17:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <vieLBomJBOv_vKe2DKKhaRNPX8QGvVtsKduHWPl9dFw=.bd73bf25-1158-4ded-9b13-f5a6f70e6227@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
 <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>
 <MLW8diuS18ZU2uDvEX1PisTd1zLs0pg7vYaku-sXaLs=.f511f704-af2f-464f-8d50-69ccdeeb5edb@github.com>
 <vieLBomJBOv_vKe2DKKhaRNPX8QGvVtsKduHWPl9dFw=.bd73bf25-1158-4ded-9b13-f5a6f70e6227@github.com>
Message-ID: <lCS8Q-IeqtdiN1giLVXJs-aAZ6kuG_PbosqN3nvvr2Y=.b4b1b6e4-720e-469d-972f-b5ac18cfbdc4@github.com>

On Thu, 30 May 2024 06:51:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hopefully the ports will catch up someday and the alternative implementation can be removed. 
>> 
>> We decided not to rename java.lang.VirtualThread when introducing the alternative implementation as it's just too disruptive. The super class that both implementations extend is BaseVirtualThread so testing for an instance of that is correct for the two implementations.
>> 
>> If it helps the readability then introducing a function to test if a thread is a virtual thread might help. It could use VMContinuations if needed but right now, testing for an instanceof BaseVirtualThread is okay.
>
> Okay. I still think that should be hidden behind the `java_lang_VirtualThread::is_instance` as it is an implementation detail the JVMTI and thread code shouldn't need to know about IMO. Once the alternative implementation is removed I expect these explicit checks for `BaseVirtualThread` will need to be reverted and we could avoid that if we make a change now.

java_lang_VirtualThread::is_instance returning true when the top is not an instance of that class would be a bit strange. java_lang_Thread::is_virtual_thread_instance might be less surprising.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1620105401

From dholmes at openjdk.org  Thu May 30 07:27:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 May 2024 07:27:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <lCS8Q-IeqtdiN1giLVXJs-aAZ6kuG_PbosqN3nvvr2Y=.b4b1b6e4-720e-469d-972f-b5ac18cfbdc4@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
 <vPVk8TNYUu0KJmPbtD_AuD-wqKcQ66e60m_wdz7drag=.5c706f74-ba23-46ef-93ac-9e723a1e789b@github.com>
 <MLW8diuS18ZU2uDvEX1PisTd1zLs0pg7vYaku-sXaLs=.f511f704-af2f-464f-8d50-69ccdeeb5edb@github.com>
 <vieLBomJBOv_vKe2DKKhaRNPX8QGvVtsKduHWPl9dFw=.bd73bf25-1158-4ded-9b13-f5a6f70e6227@github.com>
 <lCS8Q-IeqtdiN1giLVXJs-aAZ6kuG_PbosqN3nvvr2Y=.b4b1b6e4-720e-469d-972f-b5ac18cfbdc4@github.com>
Message-ID: <-hMvhFy6RQ-ydCzP2sCMueZ3JN1Sz2zgQJkn43Gtdzk=.520fc8b3-7e16-4dfd-96ee-c1856ba2a385@github.com>

On Thu, 30 May 2024 07:14:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay. I still think that should be hidden behind the `java_lang_VirtualThread::is_instance` as it is an implementation detail the JVMTI and thread code shouldn't need to know about IMO. Once the alternative implementation is removed I expect these explicit checks for `BaseVirtualThread` will need to be reverted and we could avoid that if we make a change now.
>
> java_lang_VirtualThread::is_instance returning true when the top is not an instance of that class would be a bit strange. java_lang_Thread::is_virtual_thread_instance might be less surprising.

Yes you are right, we would need a new API to answer the generic "are you a virtual thread" query.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19405#discussion_r1620123058

From sspitsyn at openjdk.org  Thu May 30 09:29:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 09:29:02 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
Message-ID: <8RMoubPJmjTCfZl2Bw8lmhVpFTLvXgEAq97F0lSFSoI=.5b93353a-afd6-44bb-8466-3089b772eff1@github.com>

On Thu, 30 May 2024 01:13:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>>   There are two changes in this PR:
>> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation.
>> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low.
>> 
>>   
>> 
>> Additional testing:
>> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140)
>> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()

Thank you for update. Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19405#pullrequestreview-2087753874

From mdoerr at openjdk.org  Thu May 30 12:12:07 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 May 2024 12:12:07 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <rFruEsMhZwzGCurCIHfRHU1YiXnIHTyCih_teJD-c1M=.e86b1370-c55c-47a7-bc90-fe954d6e76f4@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

Please note that `allocate` sets `*mem_ptr` to `nullptr` if the size is 0. This is not an error.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19450#issuecomment-2139416153

From duke at openjdk.org  Thu May 30 14:18:37 2024
From: duke at openjdk.org (Inigo Mediavilla Saiz)
Date: Thu, 30 May 2024 14:18:37 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
Message-ID: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>

Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.

-------------

Commit messages:
 - 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump

Changes: https://git.openjdk.org/jdk/pull/19482/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330846
  Stats: 117 lines in 2 files changed: 117 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482

PR: https://git.openjdk.org/jdk/pull/19482

From imediava at gmail.com  Thu May 30 14:20:49 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 30 May 2024 16:20:49 +0200
Subject: JDK-8330846 - Status check
In-Reply-To: <1919bcfb-53dd-4154-9f01-791460e722cc@oracle.com>
References: <CA+wBRWAzJUbC=U=je+ZSh9UR97_XU1LwHL6tx81GwDagCj8GTw@mail.gmail.com>
 <1919bcfb-53dd-4154-9f01-791460e722cc@oracle.com>
Message-ID: <CA+wBRWCjhc4zAUg8XpdhbxC3OAhfWs+rVy0vPdeVYQ9wjezJBg@mail.gmail.com>

Thanks Alex !

Here's a work in progress PR where I'm tackling the `jcmd <pid>
Thread.print` command:

https://github.com/openjdk/jdk/pull/19482

The JBS ticket also mentions `jstack` but I'd be in favor of doing that if
in a separate PR for simplicity, unless there's a general recommendation in
the openjdk contribution guidelines to tackle all the changes mentioned by
a JBS ticket in a single PR.

Best,

??igo

On Tue, May 28, 2024 at 7:57?PM Alex Menkov <alexey.menkov at oracle.com>
wrote:

> Hi,
>
> I'm not started with the issue, feel free to take it.
>
> --alex
>
> On 28.05.2024 7:17, I?igo Mediavilla wrote:
> > Hello,
> >
> > I'm redirecting this message here, that I posted in the beginning to the
> > loom-dev mailing list.
> >
> > I've been looking at possible tickets that I could work on in JBS, and
> > I've run into : JDK-8330846 - Add stacks of mounted virtual threads to
> > the HotSpot thread dump
> >
> > Link: https://bugs.openjdk.org/browse/JDK-8330846
> > <https://bugs.openjdk.org/browse/JDK-8330846>
> >
> > It seems to be assigned to, Alex Menkov. Alex, is it something that
> > you're working on or that you'd want to work on, or would you be OK if I
> > gave a it a try ?
> >
> > Regards
> >
> > ??igo Mediavilla Saiz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240530/2d9f3e6d/attachment-0001.htm>

From sspitsyn at openjdk.org  Thu May 30 15:36:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 May 2024 15:36:01 GMT
Subject: RFR: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to
 don't use finalization
In-Reply-To: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
References: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
Message-ID: <OGwiOQLs0cOgZ9Lks3wR1brvp03dpmLPiPPFaBlD3aE=.f4bebded-8c35-49cd-a38d-adf594d64a02@github.com>

On Tue, 28 May 2024 20:24:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
> uses cleanup() to kill debuggee process.
> 
> However, most tests kill the debuggee process explicitly. I verified that debuggee process is killed before test finishes. (Just by printing it's status.)
> 
> The fix adds a few checks debuggee.waitFor() int tests that didn't check debuggee process code.

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19437#pullrequestreview-2088643418

From stuefe at openjdk.org  Thu May 30 15:47:08 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 May 2024 15:47:08 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <jnonW-fjnPAaCNRWz98V8CH3s0YVjETd9_-P9l2kKTM=.9963b306-c047-47ac-a81b-724f627ba87e@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

I agree with David on the 24hr thing. We want others to stick to that rule, then we should keep the rule ourselves. The rule takes the pressure out of monitoring the patch flow.

But @TheRealMDoerr is right, the only logical way we can see a nullptr here is if there are no waiters/notifiers. A better solution may have been to move the memsets into their respective count > 0 conditions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19450#issuecomment-2140003043

From alanb at openjdk.org  Thu May 30 16:42:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 16:42:01 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
In-Reply-To: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
References: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
Message-ID: <6l7bRVnz6J710R8mLEwV_hUUBGmd9xicNJNG6B-aw_Y=.5866cb26-9e54-4235-a39d-3efcf88e78a8@github.com>

On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz <duke at openjdk.org> wrote:

> Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.

Thanks for take this one. Here's the result with the changes in 1a75277e.

"ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms elapsed=47.15s tid=0x00007f81670d1a00  [0x000070000e9a4000]
   Carrying virtual thread #24
	at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262)
	at java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283)
	at java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown Source)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717)
	at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641)
	at java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507)
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455)
	at java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031)
	at java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189)
   Carrying virtual thread #24
	at Main.lambda$main$0(Main.java:7)
	at java.lang.VirtualThread.run(java.base/VirtualThread.java:381)


Note that the line "Carrying virtual thread  #24" is printed twice. Also it's not immediately clear that there are two stack traces. 

You'll likely get different opinions on how mounted virtual threads should be presented.  A few things to try
- indent the stack trace of the mounted virtual thread
- list the mounted virtual threads at the end

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2140202464

From cjplummer at openjdk.org  Thu May 30 18:06:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 May 2024 18:06:07 GMT
Subject: RFR: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject [v2]
In-Reply-To: <Ql0yI6dsRk7hrOU4HHEJImvz70ZRpiqoc6k-68eeYk0=.fa5fda79-d2a0-4b2b-ac42-7b2590323cd4@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
 <Ql0yI6dsRk7hrOU4HHEJImvz70ZRpiqoc6k-68eeYk0=.fa5fda79-d2a0-4b2b-ac42-7b2590323cd4@github.com>
Message-ID: <qb8EelFmAlv09UJqTWkfbBs3IF5rdkcHs9f4IxqkoLg=.9af4fdcf-2356-4c76-a8f7-62248e0b7a14@github.com>

On Wed, 29 May 2024 01:47:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
>> - com/sun/jdi
>> - nsk/jdi
>> - nsk/jdwp
>> - nsk/jdb
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add period at end of comments

Thanks for the reviews Serguei and Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19439#issuecomment-2140499302

From cjplummer at openjdk.org  Thu May 30 18:06:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 May 2024 18:06:08 GMT
Subject: Integrated: 8328611: Thread safety issue in
 com.sun.tools.jdi.ReferenceTypeImpl::classObject
In-Reply-To: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
References: <MhigO2qJEz4dxpvLBGF53-VhHP7heA_Q0jWy5nAAFIc=.84d70986-8dcd-4bc1-b72f-8e8f65418944@github.com>
Message-ID: <x20-RYBL-jhqObNKzHGl31-Ugb7SyNEG0Eaj5FhP7hA=.b8d3b48e-17dc-4c61-90d9-b302dba025b3@github.com>

On Tue, 28 May 2024 23:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`. Details in the first comment. Tested with the following:
> - com/sun/jdi
> - nsk/jdi
> - nsk/jdwp
> - nsk/jdb

This pull request has now been integrated.

Changeset: 922e312b
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/922e312b0ab3ac54979ffdc53a8d8338e52234df
Stats:     26 lines in 1 file changed: 2 ins; 13 del; 11 mod

8328611: Thread safety issue in com.sun.tools.jdi.ReferenceTypeImpl::classObject

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/19439

From amenkov at openjdk.org  Thu May 30 18:15:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 30 May 2024 18:15:09 GMT
Subject: Integrated: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <q8qrasWkAsJVW3avp03l09CuI3Cjtg2i4ImUAtsZuks=.c86da6b0-c791-427d-8967-d72613337aa8@github.com>

On Fri, 26 Apr 2024 22:59:43 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

This pull request has now been integrated.

Changeset: 44c1845a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44c1845ae7fdff524d4a60a51362834cfea5c5da
Stats:     43 lines in 3 files changed: 3 ins; 11 del; 29 mod

8330852: All callers of JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread explicitly

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/18986

From lmesnik at openjdk.org  Thu May 30 18:24:06 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 May 2024 18:24:06 GMT
Subject: Integrated: 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java
 to don't use finalization
In-Reply-To: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
References: <Weni7tj8j6F-qHt0ygraldBhg8OULUNdxz3-p5T3CkY=.48b40fde-69dd-4f9d-a44f-1e9b3ed8cfcf@github.com>
Message-ID: <FEem4mHXTNOiWK4tE4tF4fywEgsp5qR05DcCKziUe9A=.261b1d43-2836-4287-91cb-eacb73799229@github.com>

On Tue, 28 May 2024 20:24:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
> uses cleanup() to kill debuggee process.
> 
> However, most tests kill the debuggee process explicitly. I verified that debuggee process is killed before test finishes. (Just by printing it's status.)
> 
> The fix adds a few checks debuggee.waitFor() int tests that didn't check debuggee process code.

This pull request has now been integrated.

Changeset: b3e29db1
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3e29db14466ccc64a2815224ecefab4cec4c775
Stats:     42 lines in 6 files changed: 16 ins; 21 del; 5 mod

8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to don't use finalization

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/19437

From pchilanomate at openjdk.org  Thu May 30 19:06:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 May 2024 19:06:03 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes [v2]
In-Reply-To: <55rWd_Kn3Jf8kfmkMtVnzRVs_o0KK_jnuZthiS9awDA=.555b5928-38d1-422c-9014-7d4cf31a950d@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
 <55rWd_Kn3Jf8kfmkMtVnzRVs_o0KK_jnuZthiS9awDA=.555b5928-38d1-422c-9014-7d4cf31a950d@github.com>
Message-ID: <Q3rB2nEeBOd5VdRl9-k_JCqMTlgMPa9t8yum_wnDmE0=.457fdbe8-3f1a-4204-8c55-a3f55877df27@github.com>

On Thu, 30 May 2024 02:31:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>>  
>>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>>  
>>  Testing:
>>  - Ran new test case locally
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed nits in new test

Hi Serguei,

Thanks for fixing this one.

src/hotspot/share/prims/jvmtiThreadState.cpp line 674:

> 672:   }
> 673:   // enable interp_only_mode for carrier thread if it has pending bit
> 674:   process_pending_interp_only(thread);

So for the last unmount case we will call this before doing the JVMTI state rebinding, but shouldn't it be called after it in VTMS_vthread_end? Actually why not moving this call inside rebind_to_jvmti_thread_state_of()?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19438#pullrequestreview-2089163431
PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1621298531

From ihse at openjdk.org  Thu May 30 19:20:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 30 May 2024 19:20:24 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
Message-ID: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>

The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)

This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.

It just adds clutter to the build system, and should be removed.

-------------

Commit messages:
 - 8333301: Remove static builds using --enable-static-build

Changes: https://git.openjdk.org/jdk/pull/19487/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333301
  Stats: 218 lines in 14 files changed: 4 ins; 206 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19487/head:pull/19487

PR: https://git.openjdk.org/jdk/pull/19487

From cjplummer at openjdk.org  Thu May 30 20:41:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 May 2024 20:41:07 GMT
Subject: RFR: 8332751: Broken link in VirtualMachine.html
In-Reply-To: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
References: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
Message-ID: <oIJ3lJ5tL1bzuyeqte8YmO66dIGJguaT42dCvLtxBes=.bf9f4c16-52f2-4002-a7e3-f1b3d878c413@github.com>

On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed broken javadoc link. I confirmed that it currently is broken as can be seen in the JDK 22 javadocs:
> 
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
> 
> Click on the "virtual threads" link within the allThreads() description to see the broken link. 
> 
> I verified the fix by building the javadocs and checking that the link now works.

Thanks for the reviews Alan and Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19469#issuecomment-2140825215

From cjplummer at openjdk.org  Thu May 30 20:41:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 May 2024 20:41:07 GMT
Subject: Integrated: 8332751: Broken link in VirtualMachine.html
In-Reply-To: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
References: <jJ4go5pLPMNst-E1LW25zsULvesaHMkQKgZOGhe_YYo=.9bb3f90f-c44d-4331-ac80-c96c679609d7@github.com>
Message-ID: <WpFuw7kJaiuxTNOcp5iCse1mnoLDh15HJbLUy8UrUg0=.b67918b5-3f0a-4ea2-b6eb-6de46fd9b457@github.com>

On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed broken javadoc link. I confirmed that it currently is broken as can be seen in the JDK 22 javadocs:
> 
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
> 
> Click on the "virtual threads" link within the allThreads() description to see the broken link. 
> 
> I verified the fix by building the javadocs and checking that the link now works.

This pull request has now been integrated.

Changeset: 3634a910
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3634a9105053717f3099982390ce2b9e564f0ac5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8332751: Broken link in VirtualMachine.html

Reviewed-by: amenkov, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19469

From szaldana at openjdk.org  Thu May 30 20:45:25 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 30 May 2024 20:45:25 GMT
Subject: RFR: 8332785: Replace naked uses of UseSharedSpaces with
 CDSConfig::is_using_archive
Message-ID: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>

Hi folks, 

This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785) replacing all naked uses for ```UseSharedSpaces``` with ```CDSConfig::is_using_archive```. 

Testing: 
- [x] Tier 1 with GHA. 

Thanks, 
Sonia

-------------

Commit messages:
 - Missed include statement in vmError_windows.cpp
 - 8332785: Replace naked uses of UseSharedSpaces with CDSConfig::is_using_archive

Changes: https://git.openjdk.org/jdk/pull/19463/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332785
  Stats: 99 lines in 35 files changed: 8 ins; 0 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/19463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19463/head:pull/19463

PR: https://git.openjdk.org/jdk/pull/19463

From cjplummer at openjdk.org  Thu May 30 22:59:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 May 2024 22:59:03 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <NQMDjkTJQCszBIR6NeWJwAu3NYfXuBB-CEY9o0YtoIg=.fea540e9-1063-485f-bd4a-c1aadbe4008e@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18850#pullrequestreview-2089482773

From dholmes at openjdk.org  Fri May 31 00:19:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 May 2024 00:19:07 GMT
Subject: RFR: 8333149: ubsan : memset on nullptr target detected in
 jvmtiEnvBase.cpp get_object_monitor_usage
In-Reply-To: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
References: <hfcmJNptT9nr_hRNiOngrcxVxMdjuC1_A_obkr31B7c=.71b97823-5beb-4b7b-9c33-5b6fed34ceba@github.com>
Message-ID: <pUAFjOpmXtYucOkv8H3HcMt2mTNVUGB06lnfMp00DD8=.bc11d41d-aeb2-4585-b622-bae909385108@github.com>

On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations are detected in get_object_monitor_usage .
> 
> // null out memory for robustness
> memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
> memset(ret.notify_waiters, 0, ret.notify_waiter_count * sizeof(jthread *));
> 
> probably we should add checks there.
> Example :
> vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1560:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7ffb2568559c in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1560
> debugee.stderr> #1 0x7ffb27987bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7ffb28ddc2dd in VM_Operation::evaluate() src/hotspot/share/runtime/vmOperations.cpp:75
> debugee.stderr> #3 0x7ffb28deac41 in VMThread::evaluate_operation(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:283
> debugee.stderr> #4 0x7ffb28decc4f in VMThread::inner_execute(VM_Operation*) src/hotspot/share/runtime/vmThread.cpp:427
> debugee.stderr> #5 0x7ffb28ded7b9 in VMThread::loop() src/hotspot/share/runtime/vmThread.cpp:493
> debugee.stderr> #6 0x7ffb28ded8a7 in VMThread::run() src/hotspot/share/runtime/vmThread.cpp:177
> debugee.stderr> #7 0x7ffb28b7e31a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> debugee.stderr> #8 0x7ffb281c4971 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
> debugee.stderr> #9 0x7ffb2df416e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
> debugee.stderr> #10 0x7ffb2d51550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.jtr
> 
> debugee.stderr> /src/hotspot/share/prims/jvmtiEnvBase.cpp:1561:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> debugee.stderr> #0 0x7f1e070855bb in JvmtiEnvBase::get_object_monitor_usage(JavaThread*, _jobject*, jvmtiMonitorUsage*) src/hotspot/share/prims/jvmtiEnvBase.cpp:1561
> debugee.stderr> #1 0x7f1e09387bd7 in VM_GetObjectMonitorUsage::doit() src/hotspot/share/prims/jvmtiEnvBase.hpp:594
> debugee.stderr> #2 0x7f1e0a7dc2dd in VM_Operation::evaluate() src/hotsp...

Okay, sorry, the zero case handling here is a little awkward. But it seems to me that if the counts are zero it is expected that memset does nothing, so the value of the pointer passed in is irrelevant. Shame it doesn't specify that. We should skip allocation and the subsequent memset when the count is zero.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19450#issuecomment-2141034070

From sspitsyn at openjdk.org  Fri May 31 01:41:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 01:41:17 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v3]
In-Reply-To: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
Message-ID: <RvgpUN754SZRN24oammkQ2vPgMT3t8gS26Ln9ZxDSZY=.37c589ac-9fd7-4d05-8950-eeb1c2fd47d8@github.com>

> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
> 
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
> This update is to make it clear that `nullptr` is C programming language `null` pointer.
> 
> I think we do not need a CSR for this fix.
> 
> Testing: N/A (not needed)

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: replace nullptr with null pointer in the docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19257/files
  - new: https://git.openjdk.org/jdk/pull/19257/files/9fe639e1..4e1c48a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=01-02

  Stats: 81 lines in 4 files changed: 0 ins; 0 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/19257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19257/head:pull/19257

PR: https://git.openjdk.org/jdk/pull/19257

From sspitsyn at openjdk.org  Fri May 31 01:46:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 01:46:03 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
 <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>
 <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>
Message-ID: <mzdXjY-IKUYuOlTKNF6-Acx09v7Ws6p1iZMbmFNY10g=.3fb56813-b30f-413e-8704-2fc3752df238@github.com>

On Fri, 17 May 2024 04:34:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> But this clarification doesn't actually clarify that the rest of the spec uses nullptr. Based on the proposed wording I would expect things like:
>
> The function may return <code>nullptr</code>
>
> to say
>
> The function may return a null pointer

Okay. I've made a fix to replace in the docs `nullptr` with `null pointer` as you suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2141095067

From sspitsyn at openjdk.org  Fri May 31 01:46:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 01:46:03 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v3]
In-Reply-To: <cl7GlE_WaUr0moi3xGlwunaU3EvLVWtJ89d-lX9la24=.fb301202-17c8-48c5-ae9a-a103b8ce8524@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <KD9R-pWTbNmk2X_DXiILVZWc-njmTKsT9eM3bXs8hL0=.31b72eff-aa4c-4585-bfeb-b666f27c9925@github.com>
 <k0WQywNEN45zwk5entj15wq5g-tWrbr3Y733PTozoVY=.5ff79f1a-1ab3-43de-849d-943b120871e9@github.com>
 <cl7GlE_WaUr0moi3xGlwunaU3EvLVWtJ89d-lX9la24=.fb301202-17c8-48c5-ae9a-a103b8ce8524@github.com>
Message-ID: <4eneea7A20vUtgGjOxQ0nd63PjutAtT4UsShvgys0-c=.7f0e6947-0129-4f27-a132-edbae5eedeb2@github.com>

On Fri, 17 May 2024 04:47:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you, Kim. I like this suggestion. Updated now.
>
> That part looks okay but I think all the parameters and error descriptions changed by JDK-8324680 will now need to change to use "null" instead of "nullptr".

Okay. I've made a fix to replace in the doc: `nullptr` => `null` pointer as David suggested below.
I can reduce it and remove the word 'pointer'. Please, let me know what is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1621575474

From dholmes at openjdk.org  Fri May 31 02:04:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 May 2024 02:04:05 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
In-Reply-To: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
References: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
Message-ID: <fxJg6Sq1Ej9Ey32C1RCoev7OyTm4mzNzPRqng9Ub_xc=.1d1ef851-01bc-40dc-9ce4-c315e4bb7f26@github.com>

On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz <duke at openjdk.org> wrote:

> Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.

Do you look at `JavaThread::print_vthread_stack_on`? The last thing we need is yet-another-version of stack printing code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19482#pullrequestreview-2089761057

From dholmes at openjdk.org  Fri May 31 02:10:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 May 2024 02:10:04 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
In-Reply-To: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
References: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
Message-ID: <X8jz4tb6vNIO6Rxgd_XYqUgJepa0bsw2KH4zI2dBuRs=.063e6a36-c088-40fd-9ec8-e0dc5c29b0ae@github.com>

On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz <duke at openjdk.org> wrote:

> Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.

I'd probably give preference to the stack of the virtual thread, as the stack of the carrier when a vthread is mounted is generally quite uninteresting:

"ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms elapsed=47.15s tid=0x00007f81670d1a00  [0x000070000e9a4000]
       Carrying virtual thread #24
             at Main.lambda$main$0(Main.java:7)
             at java.lang.VirtualThread.run(java.base/VirtualThread.java:381)
	at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262)
	at java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283)
	at java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown Source)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717)
	at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641)
	at java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507)
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455)
	at java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031)
	at java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2141113251

From dholmes at openjdk.org  Fri May 31 02:42:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 May 2024 02:42:02 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v2]
In-Reply-To: <mzdXjY-IKUYuOlTKNF6-Acx09v7Ws6p1iZMbmFNY10g=.3fb56813-b30f-413e-8704-2fc3752df238@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com>
 <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com>
 <iEIIWGwYdhumyrrwYWtK7fH3EFkevOUnvkv3VQfsFgg=.3c9321f7-96a8-4b4a-bbdc-6361f418b2cd@github.com>
 <mzdXjY-IKUYuOlTKNF6-Acx09v7Ws6p1iZMbmFNY10g=.3fb56813-b30f-413e-8704-2fc3752df238@github.com>
Message-ID: <qIPNrOxAM-jRhAHxt_B00xM-wxzvDKgn1_k2T-AD5PM=.186ca307-d4fd-459e-99b3-02a26ec72094@github.com>

On Fri, 31 May 2024 01:43:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Okay. I've made a fix to replace in the docs nullptr with null pointer as you suggested.

What I suggested was

> returns _a_ null pointer

in place of

> returns `nulllptr`

but "a null pointer" doesn't always look right either e.g. "was a null pointer" would be better as just "was null".

I think using non-code-font "null" to represent the concept of null-ness would be fine: "returns null", "is null", "was null"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2141136079

From dholmes at openjdk.org  Fri May 31 05:05:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 May 2024 05:05:06 GMT
Subject: RFR: 8332785: Replace naked uses of UseSharedSpaces with
 CDSConfig::is_using_archive
In-Reply-To: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
References: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
Message-ID: <x-lgwPhq57NbP_cZ9-1BryKzWotnwWE6OT3-AULQU84=.d8a4d3e6-5e28-4d08-92eb-c80966b2c46c@github.com>

On Wed, 29 May 2024 18:12:25 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785) replacing all naked uses for ```UseSharedSpaces``` with ```CDSConfig::is_using_archive```. 
> 
> Testing: 
> - [x] Tier 1 with GHA. 
> 
> Thanks, 
> Sonia

One minor nit but otherwise looks good.

Thanks

src/hotspot/share/cds/cdsConfig.cpp line 308:

> 306: 
> 307: bool CDSConfig::has_unsupported_runtime_module_options() {
> 308:   assert(CDSConfig::is_using_archive(), "this function is only used with -Xshare:{on,auto}");

Nit: you shouldn't need to specify `CDSConfig::`

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19463#pullrequestreview-2089898352
PR Review Comment: https://git.openjdk.org/jdk/pull/19463#discussion_r1621718062

From stuefe at openjdk.org  Fri May 31 06:40:01 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 May 2024 06:40:01 GMT
Subject: RFR: 8332785: Replace naked uses of UseSharedSpaces with
 CDSConfig::is_using_archive
In-Reply-To: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
References: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
Message-ID: <sIj1HWenqxy-EV94DQR0uh_GAKwJxdQVMz8Rdg0nwuI=.1b592e2e-d57f-4cc4-a814-95fd79f13870@github.com>

On Wed, 29 May 2024 18:12:25 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785) replacing all naked uses for ```UseSharedSpaces``` with ```CDSConfig::is_using_archive```. 
> 
> Testing: 
> - [x] Tier 1 with GHA. 
> 
> Thanks, 
> Sonia

Looks good, minus the nit @dholmes-ora mentioned. Please make sure Copyrights are updated.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19463#pullrequestreview-2089995893

From stuefe at openjdk.org  Fri May 31 06:53:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 May 2024 06:53:04 GMT
Subject: RFR: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <Vo4Hf7qFLxuVdoyX9NbgAOSNwXqbK210UPf43lZ271E=.7b4978ea-26b3-4869-a9ec-89524d4efc47@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
 <Vo4Hf7qFLxuVdoyX9NbgAOSNwXqbK210UPf43lZ271E=.7b4978ea-26b3-4869-a9ec-89524d4efc47@github.com>
Message-ID: <n4X0SHx5Wp9cVq2pqBmwgbvNooZk_ku9BU1Pr42g_zM=.04569396-e75e-4650-8f57-6724a00261ed@github.com>

On Wed, 29 May 2024 07:42:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
>> 
>> It contains a workaround:
>> 
>> 
>>     // lazily create the single threaded resource area
>>     // pick a size which is not a standard since the pools don't exist yet
>>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
>> 
>> 
>> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
>> 
>> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
>> 
>> ---
>> 
>> Tests: GHAs.
>> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.
>
> Today, the ChunkPools are allocated before main through static initialization. That means that the ChunkPools exists when main starts executing, so this is safe.

Thanks @jdksjolen and @sspitsyn !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19425#issuecomment-2141338912

From stuefe at openjdk.org  Fri May 31 06:53:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 May 2024 06:53:04 GMT
Subject: Integrated: 8333047: Remove arena-size-workaround in jvmtiUtils.cpp
In-Reply-To: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
References: <M23csTDoFXu8b7w2EwdgCCuUK8IwrLU1VD2t9-vdsB0=.6280a478-5d4f-40ea-8128-7d0c9679ebd3@github.com>
Message-ID: <O1lEX4sUL4nE64qEz_KVlsmdI4S3J-wMJSzkFBfbnPg=.2de65e31-2654-43ee-9177-d4b577020bf0@github.com>

On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that is supposed to work even if the current thread is not attached yet and there is no associated Thread or the Thread has no valid ResourceArea.
> 
> It contains a workaround:
> 
> 
>     // lazily create the single threaded resource area
>     // pick a size which is not a standard since the pools don't exist yet
>     _single_threaded_resource_area = new (mtInternal) ResourceArea(Chunk::non_pool_size);
> 
> 
> It specifies a non-standard chunk size to circumvent the chunk-pool-based allocation in the RA constructor, ensuring that only malloc is used. This is because in the old days the ChunkPools had been allocated from C-Heap and there was a time window when no chunk pools were live yet.
> 
> This is quirky and a bit ugly. It is also unnecessary since [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). We now create chunk pools as global objects, so they are live as soon as the libjvm C++ initialization ran. We can remove this workaround and the comment.
> 
> ---
> 
> Tests: GHAs.
> I also manually called this function, and allocated from the resulting ResourceArea, at the very beginning of CreateJavaVM. I made sure that both allocations and follow-up-chunk-allocation worked even this early in VM life.

This pull request has now been integrated.

Changeset: ba323b51
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba323b515d8821895356507bdb1e94df0776dd5a
Stats:     8 lines in 3 files changed: 0 ins; 3 del; 5 mod

8333047: Remove arena-size-workaround in jvmtiUtils.cpp

Reviewed-by: jsjolen, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/19425

From sspitsyn at openjdk.org  Fri May 31 08:07:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 08:07:36 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v4]
In-Reply-To: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
Message-ID: <778pi5AHHgXZdUEBV45R0Npj1wZPeuAHwWdrygWR830=.d67d6249-0dcd-4fef-976f-6911432d53f8@github.com>

> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
> 
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
> This update is to make it clear that `nullptr` is C programming language `null` pointer.
> 
> I think we do not need a CSR for this fix.
> 
> Testing: N/A (not needed)

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: more null pointer corrections

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19257/files
  - new: https://git.openjdk.org/jdk/pull/19257/files/4e1c48a1..48ba8f5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=02-03

  Stats: 50 lines in 1 file changed: 0 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/19257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19257/head:pull/19257

PR: https://git.openjdk.org/jdk/pull/19257

From sspitsyn at openjdk.org  Fri May 31 08:07:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 08:07:36 GMT
Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++
 developers [v3]
In-Reply-To: <RvgpUN754SZRN24oammkQ2vPgMT3t8gS26Ln9ZxDSZY=.37c589ac-9fd7-4d05-8950-eeb1c2fd47d8@github.com>
References: <F-SJUbLVm_lDVnSCqRqI-Xmm0C2wVZmqrKhXO7IwkZs=.7907dec1-2b25-4538-8ab4-3e3cfd04dc7d@github.com>
 <RvgpUN754SZRN24oammkQ2vPgMT3t8gS26Ln9ZxDSZY=.37c589ac-9fd7-4d05-8950-eeb1c2fd47d8@github.com>
Message-ID: <uV4fibmvpm-TyeNLTSIb70_jCA5GKlnOA1e6VGYZ8Yk=.09c847cf-bb14-487b-a106-56eb2a9c0c3a@github.com>

On Fri, 31 May 2024 01:41:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code
>> 
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++.
>> This update is to make it clear that `nullptr` is C programming language `null` pointer.
>> 
>> I think we do not need a CSR for this fix.
>> 
>> Testing: N/A (not needed)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace nullptr with null pointer in the docs

Thanks, David. I've done one more attempt to correct it. Please, let me know if it is wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2141435705

From jpai at openjdk.org  Fri May 31 09:06:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 09:06:11 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version
Message-ID: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>

Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?

There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.

In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).

This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.

So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.

The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.

The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.

-------------

Commit messages:
 - 8333130: MakeJAR2.sh uses hard-coded JDK version

Changes: https://git.openjdk.org/jdk/pull/19495/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333130
  Stats: 409 lines in 5 files changed: 265 ins; 131 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495

PR: https://git.openjdk.org/jdk/pull/19495

From lancea at openjdk.org  Fri May 31 11:05:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 May 2024 11:05:01 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version
In-Reply-To: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
Message-ID: <iKJA3awBFiPC5D55czoW_BDpB-rW2tSplfuKgXAiOE4=.de4ff94d-f26c-4b92-8189-2df588ca4f00@github.com>

On Fri, 31 May 2024 09:01:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
> 
> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
> 
> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
> 
> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
> 
> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
> 
> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
> 
> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.

Changes look reasonable.  Great to see the removal of the need to execute a shell script as part of the test run

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2090554946

From jpai at openjdk.org  Fri May 31 12:01:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 12:01:14 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2]
In-Reply-To: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
Message-ID: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>

> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
> 
> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
> 
> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
> 
> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
> 
> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
> 
> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
> 
> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  fix Boot-Class-Path value for Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19495/files
  - new: https://git.openjdk.org/jdk/pull/19495/files/a792b964..88997f4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=00-01

  Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495

PR: https://git.openjdk.org/jdk/pull/19495

From duke at openjdk.org  Fri May 31 12:19:01 2024
From: duke at openjdk.org (Inigo Mediavilla Saiz)
Date: Fri, 31 May 2024 12:19:01 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
In-Reply-To: <6l7bRVnz6J710R8mLEwV_hUUBGmd9xicNJNG6B-aw_Y=.5866cb26-9e54-4235-a39d-3efcf88e78a8@github.com>
References: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
 <6l7bRVnz6J710R8mLEwV_hUUBGmd9xicNJNG6B-aw_Y=.5866cb26-9e54-4235-a39d-3efcf88e78a8@github.com>
Message-ID: <d2L6guuNMOURS0xENSF5HKwFQMbaaYE4RuGY2hZC8eA=.d9fecf78-0872-4026-9a86-d95211128037@github.com>

On Thu, 30 May 2024 16:39:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.
>
> Thanks for take this one. Here's the result with the changes in 1a75277e.
> 
> "ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms elapsed=47.15s tid=0x00007f81670d1a00  [0x000070000e9a4000]
>    Carrying virtual thread #24
> 	at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262)
> 	at java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283)
> 	at java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown Source)
> 	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726)
> 	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717)
> 	at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641)
> 	at java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507)
> 	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455)
> 	at java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031)
> 	at java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189)
>    Carrying virtual thread #24
> 	at Main.lambda$main$0(Main.java:7)
> 	at java.lang.VirtualThread.run(java.base/VirtualThread.java:381)
> 
> 
> Note that the line "Carrying virtual thread  #24" is printed twice. Also it's not immediately clear that there are two stack traces. 
> 
> You'll likely get different opinions on how mounted virtual threads should be presented.  A few things to try
> - indent the stack trace of the mounted virtual thread
> - list the mounted virtual threads at the end

Thanks for your comments @AlanBateman and @dholmes-ora ! 

- The format proposed by @dholmes-ora definitely makes sense and I'll of course drop the duplicated "Carrying" statement.

- Regarding using `JavaThread::print_vthread_stack_on`, I agree that it'd be good to use it instead of creating a new way of printing stack traces. However `print_vthread_stack_on` does not have the `const` modifier so it cannot be called directly from `Thread.print_on`. Making `print_vthread_stack_on` more strict, seems to be fairly complicated and I don't know if I'd be OK with relaxing the `const` constraint in `Thread.print_on` for the purpose of reusing `print_vthread_stack_on`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2141946811

From syan at openjdk.org  Fri May 31 12:34:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 31 May 2024 12:34:23 GMT
Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java
Message-ID: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>

Hi all,
  This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file.
  No risk.

-------------

Commit messages:
 - 8333353: Delete extra empty line in CodeBlob.java

Changes: https://git.openjdk.org/jdk/pull/19499/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333353
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19499/head:pull/19499

PR: https://git.openjdk.org/jdk/pull/19499

From alanb at openjdk.org  Fri May 31 12:37:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 May 2024 12:37:01 GMT
Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot
 thread dump
In-Reply-To: <X8jz4tb6vNIO6Rxgd_XYqUgJepa0bsw2KH4zI2dBuRs=.063e6a36-c088-40fd-9ec8-e0dc5c29b0ae@github.com>
References: <rm7xKi7PuHsSHX_S2cof_HrptWo1L1gz88YK1E8sBOw=.35476cc9-8f8b-4895-8f1f-d9832cac1d4c@github.com>
 <X8jz4tb6vNIO6Rxgd_XYqUgJepa0bsw2KH4zI2dBuRs=.063e6a36-c088-40fd-9ec8-e0dc5c29b0ae@github.com>
Message-ID: <Dp6QiEetZMHR0DjZKF_g8VmS62AZO-Hrp1_-BaP-phE=.a1b29196-dda3-424e-b4c7-739b48da5b80@github.com>

On Fri, 31 May 2024 02:07:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Print the stack traces of mounted virtual threads when calling `jcmd <pid> Thread.print`.
>
> I'd probably give preference to the stack of the virtual thread, as the stack of the carrier when a vthread is mounted is generally quite uninteresting:
> 
> "ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms elapsed=47.15s tid=0x00007f81670d1a00  [0x000070000e9a4000]
>        Carrying virtual thread #24
>              at Main.lambda$main$0(Main.java:7)
>              at java.lang.VirtualThread.run(java.base/VirtualThread.java:381)
> 	at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262)
> 	at java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283)
> 	at java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown Source)
> 	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726)
> 	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717)
> 	at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641)
> 	at java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507)
> 	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455)
> 	at java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031)
> 	at java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189)

> * The format proposed by @dholmes-ora definitely makes sense 

You will different get different opinions on how it is presented. Can you also try putting a new section that lists the mounted virtual threads and their stack trace. If the virtual thread has a name then it can be shown too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2142000785

From maksim.zuev at jetbrains.com  Fri May 31 12:44:23 2024
From: maksim.zuev at jetbrains.com (Maksim Zuev)
Date: Fri, 31 May 2024 14:44:23 +0200
Subject: Stepping in debugger switches to interpretation mode
Message-ID: <CANQ2LmCb5QeoYkhLeDMjOrXQ-8sCLNNR-MWzW_24XX7qd3-kcg@mail.gmail.com>

Dear Sir/Madam,

I encountered a problem while debugging the code. I am attaching the
reproducer to this email in the* Main.java file*.

When running it with the debugger without stepping, the application runs in
less than a second (see jdb output in the *jdb_run.txt *file). However,
after performing a single step, the application is running in
interpretation mode, becoming very slow (see jdb output in the
*jdb_step.txt* file).

I assume running in the interpreter mode, as I see
*InterpreterRuntime::post_method_exit*
calls in the profiler.

Could you please help me figure out what causes the application to run in
the interpreter mode? Is this a bug or an expected behavior? Are there any
ways to work around this issue?

Best regards,
Maksim Zuev
Software developer at JetBrains
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240531/8295fd61/attachment.htm>
-------------- next part --------------
Initializing jdb ...
> stop at Main:7
Deferring breakpoint Main:7.
It will be set after the class is loaded.
> run
run Main
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint Main:7

Breakpoint hit: "thread=main", Main.main(), line=7 bci=0
7            int x = 1;

main[1] cont
> 3cc8b2e70ead788fba06f607b827bd8dcb06c6b3b234578b1200b793c75ef999
173ms

The application exited
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.java
Type: application/octet-stream
Size: 962 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240531/8295fd61/Main.java>
-------------- next part --------------
Initializing jdb ...
> stop at Main:7
Deferring breakpoint Main:7.
It will be set after the class is loaded.
> run
run Main
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint Main:7

Breakpoint hit: "thread=main", Main.main(), line=7 bci=0
7            int x = 1;

main[1] next
>
Step completed: "thread=main", Main.main(), line=9 bci=2
9            long start = System.currentTimeMillis();

main[1] cont
> 3cc8b2e70ead788fba06f607b827bd8dcb06c6b3b234578b1200b793c75ef999
51212ms

The application exited

From sgehwolf at redhat.com  Fri May 31 14:25:18 2024
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 31 May 2024 16:25:18 +0200
Subject: Stepping in debugger switches to interpretation mode
In-Reply-To: <CANQ2LmCb5QeoYkhLeDMjOrXQ-8sCLNNR-MWzW_24XX7qd3-kcg@mail.gmail.com>
References: <CANQ2LmCb5QeoYkhLeDMjOrXQ-8sCLNNR-MWzW_24XX7qd3-kcg@mail.gmail.com>
Message-ID: <a552f8f3dd38e255cbe223a2fbe87275308364c2.camel@redhat.com>

On Fri, 2024-05-31 at 14:44 +0200, Maksim Zuev wrote:
> Dear Sir/Madam,
> 
> I encountered a problem while debugging the code. I am attaching the
> reproducer to this email in?the Main.java file. 
> 
> When running it with the debugger without stepping, the application
> runs in less than a second (see jdb output in the jdb_run.txt file).
> However, after performing a single step, the application is running
> in interpretation mode, becoming very slow (see jdb output in the
> jdb_step.txt file).
> 
> I assume running in the interpreter mode, as I
> see?InterpreterRuntime::post_method_exit
> calls in the profiler.
> 
> Could you please help me figure out what causes the application to
> run in the interpreter mode? Is this a bug or an expected behavior?
> Are there any ways to work around this issue?

I think this is:
https://bugs.openjdk.org/browse/JDK-8229012

Thanks,
Severin


From sgehwolf at openjdk.org  Fri May 31 14:33:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 31 May 2024 14:33:02 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
In-Reply-To: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
References: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
Message-ID: <9T-m8cUCdsKn69wAgHPCIGi-oZ6bF-197kVuORzxdCs=.2929771f-6805-422f-b9b1-4191ee67bb9e@github.com>

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)
> 
> This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.
> 
> It just adds clutter to the build system, and should be removed.

Looks OK to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19487#pullrequestreview-2091001402

From szaldana at openjdk.org  Fri May 31 15:12:39 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Fri, 31 May 2024 15:12:39 GMT
Subject: RFR: 8332785: Replace naked uses of UseSharedSpaces with
 CDSConfig::is_using_archive [v2]
In-Reply-To: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
References: <NeU1H3GnWarNLlYl9lM-0b5aBVFLB40jZ6tIj62NEqE=.fe7d55b2-065d-41f7-b22d-47af4b10a36f@github.com>
Message-ID: <JCsRe6qXKPpGTrS8IieUYcYyXG9xOrx0E2XJUjmHLJs=.b9093615-cafe-40e2-89e7-ec832d409824@github.com>

> Hi folks, 
> 
> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785) replacing all naked uses for ```UseSharedSpaces``` with ```CDSConfig::is_using_archive```. 
> 
> Testing: 
> - [x] Tier 1 with GHA. 
> 
> Thanks, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright headers and unnecessary CDSConfig::

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19463/files
  - new: https://git.openjdk.org/jdk/pull/19463/files/f3e6b17c..ba4c0032

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19463&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19463&range=00-01

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/19463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19463/head:pull/19463

PR: https://git.openjdk.org/jdk/pull/19463

From syan at openjdk.org  Fri May 31 16:18:02 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 31 May 2024 16:18:02 GMT
Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java
In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
Message-ID: <sWLFw12IKZJGqbVJrcx9lshWM2Zx7i0ImPs7hcaTssY=.634eb58d-5e37-4bac-a738-f0321c74a1d9@github.com>

On Fri, 31 May 2024 12:29:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file.
>   No risk.

The GHA test runner report a failure `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java`, which has been recorded in [JDK-8332923](https://bugs.openjdk.org/browse/JDK-8332923), unralated to this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19499#issuecomment-2142586291

From chris.plummer at oracle.com  Fri May 31 16:24:45 2024
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 31 May 2024 09:24:45 -0700
Subject: Stepping in debugger switches to interpretation mode
In-Reply-To: <a552f8f3dd38e255cbe223a2fbe87275308364c2.camel@redhat.com>
References: <CANQ2LmCb5QeoYkhLeDMjOrXQ-8sCLNNR-MWzW_24XX7qd3-kcg@mail.gmail.com>
 <a552f8f3dd38e255cbe223a2fbe87275308364c2.camel@redhat.com>
Message-ID: <214d3181-c0bd-4399-a974-1bd9005444a0@oracle.com>


On 5/31/24 7:25 AM, Severin Gehwolf wrote:
> On Fri, 2024-05-31 at 14:44 +0200, Maksim Zuev wrote:
>> Dear Sir/Madam,
>>
>> I encountered a problem while debugging the code. I am attaching the
>> reproducer to this email in?the Main.java file.
>>
>> When running it with the debugger without stepping, the application
>> runs in less than a second (see jdb output in the jdb_run.txt file).
>> However, after performing a single step, the application is running
>> in interpretation mode, becoming very slow (see jdb output in the
>> jdb_step.txt file).
>>
>> I assume running in the interpreter mode, as I
>> see?InterpreterRuntime::post_method_exit
>> calls in the profiler.
>>
>> Could you please help me figure out what causes the application to
>> run in the interpreter mode? Is this a bug or an expected behavior?
>> Are there any ways to work around this issue?
> I think this is:
> https://bugs.openjdk.org/browse/JDK-8229012
>
> Thanks,
> Severin
>
Yes, that seems likely. It should resolve itself once you exit the 
method you were single stepping in. But as mentioned in the bug, if you 
single step in the main method of a thread, that thread will forever run 
interpreted.

Chris


From cjplummer at openjdk.org  Fri May 31 16:34:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 May 2024 16:34:00 GMT
Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java
In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
Message-ID: <FBDRlSI0JM-3sbMJWbPhrMfT7cpXUhDrv1mLzfr-Qcw=.5d620fa5-2fc2-48b8-aba7-03da4393c8c8@github.com>

On Fri, 31 May 2024 12:29:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file.
>   No risk.

Approved and trivial.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19499#pullrequestreview-2091269784

From simeon.danailov.andreev at gmail.com  Fri May 31 16:52:41 2024
From: simeon.danailov.andreev at gmail.com (S A)
Date: Fri, 31 May 2024 19:52:41 +0300
Subject: Stepping in debugger switches to interpretation mode
In-Reply-To: <a552f8f3dd38e255cbe223a2fbe87275308364c2.camel@redhat.com>
References: <CANQ2LmCb5QeoYkhLeDMjOrXQ-8sCLNNR-MWzW_24XX7qd3-kcg@mail.gmail.com>
 <a552f8f3dd38e255cbe223a2fbe87275308364c2.camel@redhat.com>
Message-ID: <CACcnpz09ZmjX75kRp87y9=vsVKYGhDJTm6p4zJ0gtKoO0TFwkA@mail.gmail.com>

On Fri, 2024-05-31 at 14:44 +0200, Maksim Zuev wrote:
> Dear Sir/Madam,
>
> I encountered a problem while debugging the code. I am attaching the
> reproducer to this email in the Main.java file.
>
> When running it with the debugger without stepping, the application
> runs in less than a second (see jdb output in the jdb_run.txt file).
> However, after performing a single step, the application is running
> in interpretation mode, becoming very slow (see jdb output in the
> jdb_step.txt file).
>
> I assume running in the interpreter mode, as I
> see InterpreterRuntime::post_method_exit
> calls in the profiler.
>
> Could you please help me figure out what causes the application to
> run in the interpreter mode? Is this a bug or an expected behavior?
> Are there any ways to work around this issue?

There is also a RHEL ticket, maybe more people can comment in the RHEL
tracker, than on the JDK ticket:

https://issues.redhat.com/browse/RHEL-3498

There is more related discussion too.

Best regards,
Simeon

On Fri, 31 May 2024 at 18:49, Severin Gehwolf <sgehwolf at redhat.com> wrote:

> On Fri, 2024-05-31 at 14:44 +0200, Maksim Zuev wrote:
> > Dear Sir/Madam,
> >
> > I encountered a problem while debugging the code. I am attaching the
> > reproducer to this email in the Main.java file.
> >
> > When running it with the debugger without stepping, the application
> > runs in less than a second (see jdb output in the jdb_run.txt file).
> > However, after performing a single step, the application is running
> > in interpretation mode, becoming very slow (see jdb output in the
> > jdb_step.txt file).
> >
> > I assume running in the interpreter mode, as I
> > see InterpreterRuntime::post_method_exit
> > calls in the profiler.
> >
> > Could you please help me figure out what causes the application to
> > run in the interpreter mode? Is this a bug or an expected behavior?
> > Are there any ways to work around this issue?
>
> I think this is:
> https://bugs.openjdk.org/browse/JDK-8229012
>
> Thanks,
> Severin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240531/12603cdd/attachment.htm>

From syan at openjdk.org  Fri May 31 17:02:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 31 May 2024 17:02:04 GMT
Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java
In-Reply-To: <FBDRlSI0JM-3sbMJWbPhrMfT7cpXUhDrv1mLzfr-Qcw=.5d620fa5-2fc2-48b8-aba7-03da4393c8c8@github.com>
References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
 <FBDRlSI0JM-3sbMJWbPhrMfT7cpXUhDrv1mLzfr-Qcw=.5d620fa5-2fc2-48b8-aba7-03da4393c8c8@github.com>
Message-ID: <QtS9CON8omeNS0X8pFoaZU7jPUQLKmRJWwloFGlnYS4=.2d2d9a6f-d590-43a6-a3d5-731616ce8b29@github.com>

On Fri, 31 May 2024 16:30:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Approved and trivial.

Thanks for the review and approved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19499#issuecomment-2142650762

From erikj at openjdk.org  Fri May 31 17:04:00 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 31 May 2024 17:04:00 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
In-Reply-To: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
References: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
Message-ID: <wwpsuVS-iZmayzK0AUkQdu6bZHQJw8jzzLv9UhbPV0g=.dfdf4b4e-2f57-41eb-a1b7-6a3d7ac3d012@github.com>

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)
> 
> This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.
> 
> It just adds clutter to the build system, and should be removed.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19487#pullrequestreview-2091321250

From darcy at openjdk.org  Fri May 31 17:09:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 May 2024 17:09:01 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2]
In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
 <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
Message-ID: <CajSa-QbczYlN4GiQG8M-eH3EOIGFhj9lVFNRxhANTw=.68429fe1-7536-401b-ab57-00c5755cbd88@github.com>

On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
>> 
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
>> 
>> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
>> 
>> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
>> 
>> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
>> 
>> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
>> 
>> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Boot-Class-Path value for Windows

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2091336086

From amenkov at openjdk.org  Fri May 31 17:27:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 31 May 2024 17:27:08 GMT
Subject: Integrated: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <PFjrsDYB9-NNvRcS-gnJkaAkyoeMEeK36MU0l-n9bCk=.0055b8de-19a3-47e2-b809-bb6350337022@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

This pull request has now been integrated.

Changeset: e4fbb15c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4fbb15c6a7b18f1ec66176080404818d3871194
Stats:     22 lines in 3 files changed: 9 ins; 4 del; 9 mod

8320215: HeapDumper can use DumpWriter buffer during merge

Reviewed-by: sspitsyn, yyang

-------------

PR: https://git.openjdk.org/jdk/pull/18850

From lmesnik at openjdk.org  Fri May 31 17:36:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 31 May 2024 17:36:07 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2]
In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
 <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
Message-ID: <7zH-GQuftpl5CMZr34giEYACj7PE3GOV4-7Vz-QGudU=.33fa90e4-b99c-467e-b4e2-33b931a09c42@github.com>

On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
>> 
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
>> 
>> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
>> 
>> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
>> 
>> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
>> 
>> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
>> 
>> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Boot-Class-Path value for Windows

Changes requested by lmesnik (Reviewer).

test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 168:

> 166: 
> 167:     private static void launchApp(final Path agentJar) throws Exception {
> 168:         final OutputAnalyzer oa = ProcessTools.executeLimitedTestJava(

Is there any reason the test uses 'executeLimitedTestJava' and not 'executeTestJava'? 
It might make sense to run it with different VM flags.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2091382349
PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1622751369

From lmesnik at openjdk.org  Fri May 31 17:37:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 31 May 2024 17:37:01 GMT
Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java
In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com>
Message-ID: <G0_FuixStMhuv0wHqRWJKLMIO-lwpMq6JH5efqLgMfk=.cb0539c8-832f-473b-83e3-ee3c2722a8a1@github.com>

On Fri, 31 May 2024 12:29:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file.
>   No risk.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19499#pullrequestreview-2091383870

From lmesnik at openjdk.org  Fri May 31 18:27:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 31 May 2024 18:27:07 GMT
Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in
 vmTestbase/nsk/share
Message-ID: <xQDsGFx-LQxV5mAuaj4-z0iE4k-OJs7LFJZaiQhZo5E=.be859db3-0cd4-4100-b0ec-0ab09d4c1821@github.com>

The fix removes finalization cleanup from vmTestbase.
The last to classes that use it are: DebugeeBinder and SocketIOPipe.
The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources.
The SocketIOPipe is used directly in AOD tests where it should be closed after test execution.

The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in  DebugeeProcess.waitFor().

The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. 

I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. 
Additionally, run all vmTestbase tests to verify there are no failures,

-------------

Commit messages:
 - removed finalization

Changes: https://git.openjdk.org/jdk/pull/19505/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307824
  Stats: 291 lines in 10 files changed: 14 ins; 271 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19505/head:pull/19505

PR: https://git.openjdk.org/jdk/pull/19505

From cjplummer at openjdk.org  Fri May 31 20:02:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 May 2024 20:02:09 GMT
Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology
 in vmTestbase/nsk/share
In-Reply-To: <xQDsGFx-LQxV5mAuaj4-z0iE4k-OJs7LFJZaiQhZo5E=.be859db3-0cd4-4100-b0ec-0ab09d4c1821@github.com>
References: <xQDsGFx-LQxV5mAuaj4-z0iE4k-OJs7LFJZaiQhZo5E=.be859db3-0cd4-4100-b0ec-0ab09d4c1821@github.com>
Message-ID: <RqYf6hLFClgeOiBVU8Q3swOgidgvzddu9osoo5ztrxg=.077b94d7-ed3e-4626-ba93-00eacacf9a90@github.com>

On Fri, 31 May 2024 18:22:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix removes finalization cleanup from vmTestbase.
> The last to classes that use it are: DebugeeBinder and SocketIOPipe.
> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources.
> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution.
> 
> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in  DebugeeProcess.waitFor().
> 
> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. 
> 
> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. 
> Additionally, run all vmTestbase tests to verify there are no failures,

test/hotspot/jtreg/vmTestbase/nsk/share/aod/DummyTargetApplication.java line 68:

> 66:         if ((signal == null) || !signal.equals(AODTestRunner.SIGNAL_FINISH))
> 67:             throw new TestBug("Unexpected signal: '" + signal + "'");
> 68:         pipe.close();

Exceptions can be thrown before you get here.

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 215:

> 213:         if (binder != null) {
> 214:             binder.close();
> 215:         }

Won't this be skipped if there is an exception during `waitForDebugee` or `waitForRedirectors`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1622898244
PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1622896237

From sspitsyn at openjdk.org  Fri May 31 20:56:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 20:56:03 GMT
Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected
 waiter_count [v3]
In-Reply-To: <TvJGm5rM65eCaKsEXeHiThcNnTdBathC-5pfDoOl1zA=.86ca0deb-a475-4e0e-aad8-0885be131d8f@github.com>
References: <kdwawsk6gVbZ2eoIgY-h4f8-SANJIHt62pLvG-oiRXk=.2fdd042b-783b-41ae-895f-90d6353cf33f@github.com>
 <BKFVSwKgQJU1yMlQCocv3AvKfMXmnBUCSjph-1Uie-E=.2a101a5d-1c58-48d8-b4da-c46947bb2377@github.com>
 <TvJGm5rM65eCaKsEXeHiThcNnTdBathC-5pfDoOl1zA=.86ca0deb-a475-4e0e-aad8-0885be131d8f@github.com>
Message-ID: <-UH24s5PIR3KlRVputkwVbhDKtZ2oHzF049llibV9Dk=.da5be84f-1ae3-4b1f-a779-27aa339d1049@github.com>

On Thu, 30 May 2024 06:36:09 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads()
>
> The GHA test runner report a intermittent failure `ToolTabSnippetTest.testCleaningCompletionTODO(): failure`, which has been recorded in [JDK-8287078](https://bugs.openjdk.org/browse/JDK-8287078), I think it's unrelated to this PR.

@sendaoYan The serviceability fixes require two reviews. Please, wait for a second reviewer before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2142964196

From dcubed at openjdk.org  Fri May 31 21:07:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 31 May 2024 21:07:03 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2]
In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
 <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
Message-ID: <eAgtvJ6DFcJTvhAWKCDttBdE48Q1OL4-GUH7iA3jsts=.59700e55-aa1a-49d7-b459-9bd2337cfbdf@github.com>

On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
>> 
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
>> 
>> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
>> 
>> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
>> 
>> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
>> 
>> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
>> 
>> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Boot-Class-Path value for Windows

Ping @sspitsyn - who handles JLI/JPLIS reviews for the Serviceability team?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2142976174

From amenkov at openjdk.org  Fri May 31 23:43:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 31 May 2024 23:43:02 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2]
In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
References: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>
 <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com>
Message-ID: <ARtI23RtfV2F7OMin_e8hZ3j7khGAM1YIBxRT9rTfVM=.87902e2b-2e26-40e7-946a-45fc00f13af1@github.com>

On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?
>> 
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.
>> 
>> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).
>> 
>> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.
>> 
>> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.
>> 
>> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.
>> 
>> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Boot-Class-Path value for Windows

The fix looks over-complicated.
I think it can be done by something like:
- `@build NativeMethodPrefixAgent bootreporter.StringIdCallback bootreporter.StringIdCallbackReporter` (maybe `@compile` to specify `--release`)
- use jdk.test.lib.helpers.ClassFileInstaller:

    ClassFileInstaller.writeJar("NativeMethodPrefixAgent.jar",
                                ClassFileInstaller.Manifest.fromString(manifest),
                                "NativeMethodPrefixAgent",
                                "asmlib.Instrumentor",
                                "bootreporter.StringIdCallback",
                                "bootreporter.StringIdCallbackReporter");

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2143117731

From sspitsyn at openjdk.org  Fri May 31 23:55:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 23:55:20 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes [v3]
In-Reply-To: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
Message-ID: <tNyWX_MKxdLhZ-wxhDQIlPF3JNXmcnq5zOUq-xq_-34=.6ae85273-90ed-4109-a813-c512feb7a2ab@github.com>

> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>  
>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>  
>  Testing:
>  - Ran new test case locally
>  - Ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: refactored def and use of process_pending_interp_only()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19438/files
  - new: https://git.openjdk.org/jdk/pull/19438/files/2f75975f..19e4d8fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=01-02

  Stats: 36 lines in 4 files changed: 16 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19438/head:pull/19438

PR: https://git.openjdk.org/jdk/pull/19438

From sspitsyn at openjdk.org  Fri May 31 23:58:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 May 2024 23:58:07 GMT
Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread
 can lead to crashes [v2]
In-Reply-To: <Q3rB2nEeBOd5VdRl9-k_JCqMTlgMPa9t8yum_wnDmE0=.457fdbe8-3f1a-4204-8c55-a3f55877df27@github.com>
References: <uEqyxeiMA3yyYi_isfF_TSpPiB9qBlJ3EfQtUn_KF3Q=.fe66d52a-053f-49e4-bde7-9fff990f5643@github.com>
 <55rWd_Kn3Jf8kfmkMtVnzRVs_o0KK_jnuZthiS9awDA=.555b5928-38d1-422c-9014-7d4cf31a950d@github.com>
 <Q3rB2nEeBOd5VdRl9-k_JCqMTlgMPa9t8yum_wnDmE0=.457fdbe8-3f1a-4204-8c55-a3f55877df27@github.com>
Message-ID: <6wadlhiKWk4vvtNXh3UGCf7o9giMAQENl13TZ-gTjc4=.d60fa68f-ebef-4ac3-a7c7-fe16c9cc6438@github.com>

On Thu, 30 May 2024 18:59:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed nits in new test
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 674:
> 
>> 672:   }
>> 673:   // enable interp_only_mode for carrier thread if it has pending bit
>> 674:   process_pending_interp_only(thread);
> 
> So for the last unmount case we will call this before doing the JVMTI state rebinding, but shouldn't it be called after it in VTMS_vthread_end? Actually why not moving this call inside rebind_to_jvmti_thread_state_of()?

Thank you for the comment!
I was also thinking about placing it to the `rebind_to_jvmti_thread_state_of()`. 
I've made  and pushed this change now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623046562