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: References: Message-ID: On Tue, 30 Apr 2024 02:05:10 GMT, Serguei Spitsyn 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: References: Message-ID: <-p7pqoYebg7hw2X1zB4TKN_xf6L0ZAaKA1uB8ajkPDo=.9620a1b6-49cc-4545-86ae-94d1c10d7596@github.com> On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn 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 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: 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: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com> Message-ID: On Tue, 30 Jan 2024 12:13:05 GMT, Per Lundberg 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//root/`). In other words: > > * The code for creating the socket would correctly check if `pid != ns_pid` and then act accordingly (`/proc//root/` or just plain ``) > * The code for reading the socket would not have the check the above. It would resort to always use `/proc//root/`. > * 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 `` 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: References: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com> Message-ID: On Wed, 1 May 2024 17:30:05 GMT, Larry Cable 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//root/`). In other words: >> >> * The code for creating the socket would correctly check if `pid != ns_pid` and then act accordingly (`/proc//root/` or just plain ``) >> * The code for reading the socket would not have the check the above. It would resort to always use `/proc//root/`. >> * 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 `` 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//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//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: References: Message-ID: On Fri, 12 Apr 2024 02:17:34 GMT, Alex Menkov 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 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: References: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com> Message-ID: <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com> On Wed, 1 May 2024 17:47:47 GMT, Sebastian L?vdahl 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//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//root/tmp` first, and if it cannot be read, fall back to `/tmp`. c.f: /proc//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: References: Message-ID: On Tue, 30 Apr 2024 12:08:21 GMT, Jaikiran Pai 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: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@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 wrote: >> Do you mean that it should compare the input PID against the outermost (leftmost) PID in the `NSpid` list from `/proc//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//root/tmp` first, and if it cannot be read, fall back to `/tmp`. > > c.f: /proc//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: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com> <_6stIAMnginxB40z591qcVZck2XkEiJl0s5sIDCGqcI=.21b9875b-6d9f-4567-9df0-2d4ed07213f9@github.com> <7Syh73jRLW_T1RX1pKDT0YGFrCrhDz0GA8hh8p0gVdc=.cdff1cef-6885-479f-9290-117992fea52a@github.com> Message-ID: On Wed, 1 May 2024 20:07:00 GMT, Larry Cable wrote: >> c.f: /proc//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//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//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: On Wed, 1 May 2024 21:32:46 GMT, Chris Plummer 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//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//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//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: On Wed, 1 May 2024 10:20:52 GMT, Serguei Spitsyn 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: > 8258: > 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 0 if owned by a virtual thread or not owned src/hotspot/share/prims/jvmti.xml line 8266: > 8264: > 8265: The number of platform threads waiting to own this monitor, > 8266: or 0 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: > 8278: The number of platform threads waiting to be notified by this monitor, > 8279: or 0 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 nullptr " I don't think we should be introducing `nullptr` 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 nullptr " > 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 nullptr " > 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:21:25 GMT, Chris Plummer 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: >> 8258: >> 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 0 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:21:28 GMT, Chris Plummer 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: >> 8265: The number of platform threads waiting to own this monitor, >> 8266: or 0 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 0 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:30:54 GMT, Chris Plummer 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: >> 8278: The number of platform threads waiting to be notified by this monitor, >> 8279: or 0 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:40:35 GMT, Chris Plummer 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 nullptr " > > I don't think we should be introducing `nullptr` 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 nullptr " >> 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 21:03:31 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> On Wed, 1 May 2024 22:40:02 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 8266: >> >>> 8264: >>> 8265: The number of platform threads waiting to own this monitor, >>> 8266: or 0 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 0 > 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 0 > 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//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//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//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> <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> Message-ID: On Wed, 1 May 2024 23:16:09 GMT, Chris Plummer 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 0 >> 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 0 >> 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> Message-ID: On Thu, 2 May 2024 00:51:20 GMT, Serguei Spitsyn 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> <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> Message-ID: On Wed, 1 May 2024 23:17:58 GMT, Chris Plummer 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: References: Message-ID: > 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: References: Message-ID: <8Xpm3fH_1mWw283vz0-cQAzLc5D3gUHedRsSC0Eb6zY=.8e2672a3-d81b-4d3d-8fe1-a04fb221a3aa@github.com> On Wed, 1 May 2024 19:02:29 GMT, Chris Plummer 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: References: Message-ID: On Wed, 1 May 2024 19:15:17 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> Message-ID: <3PBlt6Id-KHcyBKctS2jcAxbKFQuAQRlG1kIWHwnDWk=.956935c8-0a78-4778-8875-f378414aa94e@github.com> On Thu, 2 May 2024 02:47:19 GMT, David Holmes 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 0 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <1zzFr4VCy2uAwXew1jEUuLVXpylbM06Vb7wqbhbzCPg=.efc7adf8-185f-4942-a40f-9a13953a2687@github.com> Message-ID: On Thu, 2 May 2024 02:49:35 GMT, David Holmes 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> On Wed, 1 May 2024 21:11:36 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 21:01:16 GMT, Chris Plummer 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: > 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: References: Message-ID: On Tue, 30 Apr 2024 18:54:09 GMT, Alex Menkov 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: Interesting, TIL about /proc//ns. I tried to look for something like that but couldn't find anything relevant in /proc//status. So, a pixel perfect solution could compare these IDs to know whether /tmp or /proc//root/tmp should be used. > 2. jcmd treats it as a heuristic and attempts each way during the socket file read - first /proc//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//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//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//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: 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: 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: References: <8dbbf69e3bdc40739070d850f37d3e5b@iso-ne.com> <63aabb01-a5f5-4d60-8d0b-c15de4ed74c1@oracle.com> Message-ID: <8559e222-b29e-4984-956b-236f2e0e79c2@oracle.com> On 5/2/24 3:09 AM, Sebastian L?vdahl wrote: > Interesting, TIL about /proc//ns. I tried to look for something > like that but couldn't find anything relevant in /proc//status. ok > > So, a pixel perfect solution could compare these IDs to know whether > /tmp or /proc//root/tmp should be used. > > > 2. jcmd treats it as a heuristic and attempts each way during the > socket file read - first /proc//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//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//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//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//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//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: References: Message-ID: On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl 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: References: 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 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: References: Message-ID: On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl 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.(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.(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: 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: Thank you, Larry - that /proc//ns/mnt test makes a lot of sense to me, and I learned something new today! Jim -----Original Message----- From: serviceability-dev 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//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//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//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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn 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: > 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: `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: References: Message-ID: On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: References: Message-ID: <168Z8R7UX0uYymkZ_NCW17QbrwLu_82rg0j4nJ895_E=.5e1c4624-770f-4e94-9588-797982c2cca9@github.com> On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 2 May 2024 16:56:11 GMT, Stefan Karlsson 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: References: Message-ID: On Thu, 2 May 2024 17:04:44 GMT, Stefan Karlsson 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: References: Message-ID: <8rTp30vldMrfGYMh6uP-tirE9bjNGTBePOSztx95MD4=.8f9cdead-0301-42c4-acad-a2bfc26b4702@github.com> On Thu, 2 May 2024 17:23:21 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@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 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: On Wed, 1 May 2024 21:32:46 GMT, Chris Plummer 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: References: Message-ID: On Tue, 30 Apr 2024 18:54:09 GMT, Alex Menkov 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 2 May 2024 02:40:36 GMT, Alex Menkov 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: References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com> Message-ID: <7mbaVxLkGeEnczjYFmrAtu3vtwdZmZxgH06ZxAradkY=.e8ff6e41-4fea-4517-86d3-89f432b37ccd@github.com> On Sat, 20 Apr 2024 03:04:23 GMT, Chris Plummer 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> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> Message-ID: On Thu, 2 May 2024 06:45:39 GMT, Serguei Spitsyn 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn 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: > 8279: The number of platform threads waiting to own this monitor, or 0 > 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> Message-ID: <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> On Thu, 2 May 2024 21:36:27 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:42:16 GMT, Chris Plummer 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 nullptr " >> 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: References: Message-ID: On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai 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: <8Xpm3fH_1mWw283vz0-cQAzLc5D3gUHedRsSC0Eb6zY=.8e2672a3-d81b-4d3d-8fe1-a04fb221a3aa@github.com> Message-ID: On Thu, 2 May 2024 03:57:42 GMT, Jaikiran Pai 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: References: 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 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 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: References: Message-ID: <7DToDczTkXlyv-tvpHtlVJA33LDsAfV_2t7uzQ5SNSI=.b68b2474-eb3e-4e89-a84f-42403104585a@github.com> On Tue, 30 Apr 2024 23:48:02 GMT, Alex Menkov 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: References: Message-ID: <5jmKQ3eqaYVEG5niaFpjNT4F4wKyjufHXTv_AbWTp2U=.7df58d35-552a-4677-ac59-8902ef4ad42c@github.com> On Tue, 30 Apr 2024 23:48:02 GMT, Alex Menkov 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: References: Message-ID: > 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> <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 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Thu, 2 May 2024 21:44:43 GMT, Chris Plummer 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: >> 8279: The number of platform threads waiting to own this monitor, or 0 >> 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> <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 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: References: Message-ID: On Thu, 2 May 2024 22:40:02 GMT, Chris Plummer 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: References: Message-ID: On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: References: 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 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Fri, 3 May 2024 06:40:07 GMT, Alan Bateman wrote: >> src/hotspot/share/prims/jvmti.xml line 8280: >> >>> 8278: >>> 8279: The number of platform threads waiting to own this monitor, or 0 >>> 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 { The number of platform threads waiting to own this monitor, or 0 - 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 ------------- 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> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> Message-ID: On Thu, 2 May 2024 21:47:50 GMT, Chris Plummer 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: References: 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: References: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com> Message-ID: On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe 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: <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 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: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com> Message-ID: On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe 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: References: Message-ID: > 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: References: Message-ID: On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil 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: References: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com> Message-ID: On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf 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: References: Message-ID: On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl 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.(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//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: References: 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 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.(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//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: References: Message-ID: <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com> On Thu, 2 May 2024 10:13:51 GMT, Sebastian L?vdahl 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//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//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: References: Message-ID: <_OZZbnPJvcnrwvlHdh9i-_kEBHdK3QEo_qGfG_nE3XE=.536f045e-65e6-4a37-a22a-080476bf9a21@github.com> On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: <_OZZbnPJvcnrwvlHdh9i-_kEBHdK3QEo_qGfG_nE3XE=.536f045e-65e6-4a37-a22a-080476bf9a21@github.com> Message-ID: On Fri, 3 May 2024 18:31:21 GMT, Chris Plummer 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com> Message-ID: On Fri, 3 May 2024 12:49:03 GMT, Albert Mingkun Yang 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: > 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: References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com> Message-ID: On Mon, 22 Apr 2024 11:21:15 GMT, Andrey Turbanov 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: On Wed, 17 Apr 2024 20:19:49 GMT, Leonid Mesnik 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: References: Message-ID: On Fri, 3 May 2024 01:54:24 GMT, Alex Menkov 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: References: Message-ID: On Wed, 1 May 2024 14:14:22 GMT, SendaoYan 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: References: 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//ns/mnt == /proc//ns/mnt), return "/tmp" 2) if they are not in the same mnt ns: ??? - test the /proc//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//cwd? - Larry On 5/3/24 9:43 AM, Sebastian L?vdahl wrote: > > 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.(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//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 > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: On Sat, 4 May 2024 10:22:06 GMT, Serguei Spitsyn 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: > 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: References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com> Message-ID: On Mon, 22 Apr 2024 11:21:33 GMT, Andrey Turbanov 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: References: Message-ID: On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai 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: References: <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com> Message-ID: <-Vn0Bjjlrq0l5PlHprZIFIETB5YUhw9MQLKh9cKO6LA=.262cec6e-865d-4d55-be6c-d60a08934d08@github.com> On Sat, 4 May 2024 02:39:38 GMT, Guoxiong Li 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: References: Message-ID: > 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: References: Message-ID: <6hpNRaO10dRNfshEfX3RHSxY5lcxrLeU1wH7zUDqTlA=.40086db0-2a55-4735-8a78-13f154e9155d@github.com> On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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: <8rTp30vldMrfGYMh6uP-tirE9bjNGTBePOSztx95MD4=.8f9cdead-0301-42c4-acad-a2bfc26b4702@github.com> Message-ID: On Thu, 2 May 2024 17:26:58 GMT, Stefan Karlsson 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: References: Message-ID: On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev 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 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: References: Message-ID: > 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: <2E8psdsbHlnXaWjLMnhAHsoywFxY-jWEhHqAU4699_8=.83ba590a-2357-4924-a74a-e972b70b60da@github.com> <-Vn0Bjjlrq0l5PlHprZIFIETB5YUhw9MQLKh9cKO6LA=.262cec6e-865d-4d55-be6c-d60a08934d08@github.com> Message-ID: On Mon, 6 May 2024 09:12:47 GMT, Albert Mingkun Yang 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: <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//cwd is also restricted in the same way as /proc//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//ns/mnt == /proc//ns/mnt), return "/tmp" > 2) if they are not in the same mnt ns: > ??? - test the /proc//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//cwd? > > - Larry > > > On 5/3/24 9:43 AM, Sebastian L?vdahl wrote: >> >> 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.(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//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 >> , >> or unsubscribe >> . >> You are receiving this because you were mentioned.Message ID: >> >> > -- 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: 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: <3Z15oBbmtC2v3GeQt8P4Y0PN-R9HRhw9DkMrCh0MREM=.b7649854-6815-4cb0-ae59-47f9cb984198@github.com> Message-ID: On Fri, 3 May 2024 17:40:54 GMT, jdoylei 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//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//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//root`, `/proc//cwd` and `/proc//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: <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//cwd is also restricted in the same way > as /proc//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//ns/mnt == /proc//ns/mnt), return >> "/tmp" >> 2) if they are not in the same mnt ns: >> ??? - test the /proc//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//cwd? >> >> - Larry >> >> >> On 5/3/24 9:43 AM, Sebastian L?vdahl wrote: >>> >>> 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.(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//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 >>> , >>> or unsubscribe >>> . >>> You are receiving this because you were mentioned.Message ID: >>> >>> >> > > -- > 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: 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: References: Message-ID: > 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: References: Message-ID: <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com> On Mon, 6 May 2024 17:29:05 GMT, Sebastian L?vdahl 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: References: Message-ID: On Mon, 6 May 2024 17:29:05 GMT, Sebastian L?vdahl 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 > . > 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. > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > 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 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 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

On 5/6/24 10:35 AM, Sebastian L?vdahl wrote:

I pushed an updated attempt at this now with d3e26a0. 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 . 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, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/19055/c2096564990@github.com>



 /*
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-- ------------- 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: 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: > 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 2 May 2024 21:00:52 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 2 May 2024 21:09:42 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 2 May 2024 21:02:17 GMT, Chris Plummer 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 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@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 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: References: Message-ID: On Mon, 6 May 2024 17:05:47 GMT, Matias Saavedra Silva 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 2 May 2024 21:14:06 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer 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: On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo 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: References: Message-ID: On Mon, 6 May 2024 22:32:12 GMT, Chris Plummer 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: <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//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 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: References: Message-ID: > 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: References: Message-ID: On Wed, 1 May 2024 14:14:22 GMT, SendaoYan 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: > 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@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 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: On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo 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: References: Message-ID: On Tue, 7 May 2024 16:38:23 GMT, Matias Saavedra Silva 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: On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo 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: On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo 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: References: Message-ID: > 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: References: Message-ID: <40LMGV6OhwHexuWxyK2oZbEas-9M0KRYZ6mTXjC3RrY=.48e4b054-a66a-46e3-8bd6-eb07bf4fdc05@github.com> On Tue, 7 May 2024 17:43:02 GMT, Chris Plummer 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: References: Message-ID: On Wed, 8 May 2024 01:19:05 GMT, SendaoYan 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: References: Message-ID: On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai 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: References: Message-ID: On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote: >> Currently jcmd command GC.heap_dump only works with an additionally provided file name. >> Syntax : GC.heap_dump [options] >> >> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the is optional. >> In case the filename is NOT set, we take the HeapDumpPath (file or directory); >> >> new syntax : >> GC.heap_dump [options] .. 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: References: 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: References: Message-ID: On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 30 Apr 2024 09:54:40 GMT, Jaikiran Pai 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 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: References: Message-ID: On Wed, 8 May 2024 07:37:52 GMT, Serguei Spitsyn 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> <9kxb-BEbxmIjxykz-tEOVoGFVovZLhHkvfIj8XmuczU=.14c134f7-234f-4df2-b288-ed5527a176a2@github.com> Message-ID: On Tue, 7 May 2024 18:54:37 GMT, Chris Plummer 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: References: Message-ID: On Wed, 8 May 2024 01:19:05 GMT, SendaoYan 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> On Tue, 7 May 2024 18:53:23 GMT, Chris Plummer 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> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 15:44:37 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote: >> Currently jcmd command GC.heap_dump only works with an additionally provided file name. >> Syntax : GC.heap_dump [options] >> >> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the is optional. >> In case the filename is NOT set, we take the HeapDumpPath (file or directory); >> >> new syntax : >> GC.heap_dump [options] .. 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> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 16:46:33 GMT, Serguei Spitsyn 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> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 15:47:09 GMT, Serguei Spitsyn 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 18:27:15 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@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 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 19:09:18 GMT, Chris Plummer 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> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 20:23:21 GMT, Serguei Spitsyn 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 20:34:01 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 21:44:37 GMT, Serguei Spitsyn 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: <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 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//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//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_ file can be written to 'cwd' the actual attach socket file .java_ 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: <6gQJrENv-zCFLSR0gpJuOsNkASI-roBKYj2906olmeo=.68cdb4de-1595-42a7-ac88-f510bf40b317@github.com> Message-ID: 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//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//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//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 SELF_MNT_NS; + private static final Optional 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 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 tgt = ProcessHandle.of(pid); + Optional ph = tgt; + long nsPid = ns_pid; + Optional prevPidNS = Optional.empty(); + + while (ph.isPresent()) { + final var curPid = ph.get().pid(); + + final var procPidPath = PROC.resolve(Long.toString(curPid)); + + Optional 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 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: References: Message-ID: On Tue, 7 May 2024 16:38:23 GMT, Matias Saavedra Silva 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: On Wed, 8 May 2024 20:10:15 GMT, Serguei Spitsyn 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 22:10:29 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 22:40:26 GMT, Serguei Spitsyn 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 22:53:06 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> Message-ID: <0Q9BjsrZpbcMR5LIOgbUQ8pVRQXMS8NS6ohxDLfdHys=.457a0cc3-898d-4344-b909-9d717190b8b0@github.com> On Wed, 8 May 2024 22:41:45 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Wed, 8 May 2024 23:48:08 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 8 May 2024 16:39:33 GMT, Chris Plummer 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: References: Message-ID: On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou 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: On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter 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::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: > 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: References: Message-ID: > 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: References: Message-ID: On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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: References: Message-ID: <77xRfJh_yNfE406Tl9KCpkdlOvGQGzayTUe3fuej-QQ=.3d33f404-3a20-4836-91aa-00469a46018f@github.com> On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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 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: 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Thu, 9 May 2024 01:00:52 GMT, Chris Plummer 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: References: Message-ID: <6bT9AIygcEud6XlOjx-uuGdQk2DfcU83UZUqnB_dWpQ=.41cd47df-61d0-4e54-a184-7d08bc13783b@github.com> On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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: References: Message-ID: On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn 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 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: References: Message-ID: <1r0sJodflVOfjAZUGtDP6d9My-qDOyqaAWf22sH8BNc=.1974d8bb-2c9d-4843-9a3f-86d0e083c1e4@github.com> On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls 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: References: Message-ID: <5oaRaNCDV8gAdhI9q-UD8vbmxMygkANgOJTylyZIP1Q=.0a4d793b-1dcf-41b9-abdc-81b838be078d@github.com> On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls 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: References: Message-ID: On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls 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 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: References: Message-ID: > 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: References: Message-ID: On Thu, 9 May 2024 18:31:24 GMT, Matias Saavedra Silva 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: References: 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: References: Message-ID: On Wed, 8 May 2024 01:19:05 GMT, SendaoYan 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 6 May 2024 21:42:10 GMT, Chris Plummer 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: References: Message-ID: On Thu, 9 May 2024 21:26:07 GMT, Daniel D. Daugherty 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: References: Message-ID: <9cOTNRj5EgyWRkI0hRuNjxym6vY29_GzTJdh4f-JstI=.4c216b65-b596-41f1-9ec1-3720ddca5577@github.com> On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Tue, 7 May 2024 21:39:04 GMT, Chris Plummer 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: References: Message-ID: <1BtZbZp_vkiEPIf3xDeZ05CSCh6mnZ2p3qobDuM-aa0=.acaf9e28-1d99-48ee-90fd-0878c99b8ff6@github.com> On Mon, 6 May 2024 17:05:47 GMT, Matias Saavedra Silva 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 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: <3KivzgORzLhAreonPr-CJki3nXgPznlKMpqI4fQCWuk=.f44a8b19-56e6-4809-ac7b-659d700407af@github.com> Message-ID: On Wed, 8 May 2024 10:04:15 GMT, Albert Mingkun Yang 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: References: Message-ID: > 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: 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: References: Message-ID: On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe 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: References: Message-ID: On Tue, 30 Apr 2024 01:49:31 GMT, Serguei Spitsyn 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: On Mon, 6 May 2024 22:19:10 GMT, Chris Plummer 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: > 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: References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com> Message-ID: On Sun, 12 May 2024 02:55:45 GMT, Lei Zaakjyu 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: References: Message-ID: On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe 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: References: Message-ID: <5jtxG7mdbPDU7_iroUJP04Kut6e7o1_5XF2Ht_L9ciE=.67b51646-bcab-4fe8-a192-9d8e63a3e31b@github.com> On Mon, 6 May 2024 18:31:06 GMT, Larry Cable 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 >> . >> 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. >> >> ? >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> 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: On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin 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: On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik 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: References: 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 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: References: Message-ID: > 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: References: Message-ID: On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe 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: On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla 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: On Sun, 12 May 2024 06:01:27 GMT, Lei Zaakjyu 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: References: Message-ID: On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe 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: 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: References: Message-ID: On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore 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: References: Message-ID: > 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: References: Message-ID: On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore 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: References: Message-ID: > 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: On Thu, 9 May 2024 08:18:41 GMT, David Holmes 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: 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: References: Message-ID: <_Hf9ur_fzBA6MysoCZHn7KAjJwC0ubP8v4SKBvethOw=.63d58c21-c8ef-4b5a-b878-7fd330e0d654@github.com> On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: Message-ID: On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore 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: References: Message-ID: On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: Message-ID: On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore 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: References: Message-ID: On Mon, 13 May 2024 13:52:17 GMT, Dmitry Chuyko 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: References: Message-ID: On Mon, 13 May 2024 10:16:36 GMT, Stefan Karlsson 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: References: Message-ID: On Mon, 13 May 2024 10:13:50 GMT, Stefan Karlsson 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: References: Message-ID: <7kfgb5FXqda4SzqPO2XUXdx6CM_Z-G970nSpqvJVSYw=.b6b01073-66af-4c7d-8d7c-528a4f87707d@github.com> On Mon, 13 May 2024 14:21:35 GMT, Evgeny Astigeevich 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: <7kfgb5FXqda4SzqPO2XUXdx6CM_Z-G970nSpqvJVSYw=.b6b01073-66af-4c7d-8d7c-528a4f87707d@github.com> Message-ID: On Mon, 13 May 2024 14:34:50 GMT, Dmitry Chuyko 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: Message-ID: On Mon, 13 May 2024 14:31:22 GMT, Thomas Stuefe 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: References: Message-ID: <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com> On Mon, 13 May 2024 14:44:05 GMT, Stefan Karlsson 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: References: Message-ID: On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore 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: <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 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: <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com> <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com> Message-ID: On Mon, 13 May 2024 15:36:13 GMT, Stefan Karlsson 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: On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik 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: On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik 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: References: Message-ID: On Mon, 13 May 2024 14:42:26 GMT, Evgeny Astigeevich 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: 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: On Sat, 11 May 2024 11:12:44 GMT, Lei Zaakjyu 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: References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com> Message-ID: On Sun, 12 May 2024 03:04:45 GMT, Lei Zaakjyu 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: References: Message-ID: <4m9MF6p8mpiKijVsc-mg0IDBQE9lLvPZQjqzZeV1kQo=.97de93cf-8f20-406a-886b-a7c98bd3ccb1@github.com> On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Thu, 9 May 2024 21:40:42 GMT, David Holmes 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <7PULAuTv4f0Z8rN0G3gS6Vgp4Y-gRpdSzQpWvZvZkik=.84c73fbe-821a-45c5-9022-724ac6e86bae@github.com> <8EA0qSJdlg2PMqw3fLuEzI-cg5NTxCC1hvIwd4ZKy_M=.78daa01b-bb55-4ab2-bb59-28127acbebb4@github.com> Message-ID: On Thu, 9 May 2024 12:32:12 GMT, Serguei Spitsyn 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: On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla 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: > 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: References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@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 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: References: Message-ID: On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov 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: References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com> Message-ID: On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: Message-ID: <43tyZlzDKG1-M3YMBjjSKx2R3OosZuyfQySaBuV_KTc=.45597f64-6ff7-4d83-8416-aa29154d92df@github.com> On Mon, 13 May 2024 16:29:35 GMT, Vladimir Kozlov 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 13 May 2024 18:32:45 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 13 May 2024 21:47:32 GMT, Alex Menkov 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: <43tyZlzDKG1-M3YMBjjSKx2R3OosZuyfQySaBuV_KTc=.45597f64-6ff7-4d83-8416-aa29154d92df@github.com> Message-ID: On Mon, 13 May 2024 20:46:06 GMT, Evgeny Astigeevich 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: References: Message-ID: On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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: References: Message-ID: On Thu, 9 May 2024 07:50:00 GMT, Julian Waters 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: References: Message-ID: On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore 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: References: Message-ID: On Wed, 1 May 2024 14:14:22 GMT, SendaoYan 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 Committer: Serguei Spitsyn 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: References: Message-ID: On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov 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: References: Message-ID: On Wed, 8 May 2024 01:19:05 GMT, SendaoYan 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: References: <3E6BcBm0RVHLAGmuNjoYoeNs5-JLcYT5KgKVfmcxYAc=.4537bffa-ea3c-43f2-bc13-16710444b355@github.com> <6qHBMgu-ZgoMPPym-sSJJR9szoVattW-JuHeXaX4JY0=.05710a47-19fe-48ba-920c-218c16473fbb@github.com> Message-ID: On Mon, 13 May 2024 15:48:43 GMT, Stefan Karlsson 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: References: Message-ID: <7X2GeAXsh_ukEC7SeVR_U0VlLveqVb7qOrjrO0cK76U=.8db41eba-86fd-4943-b403-283b467f0392@github.com> On Mon, 13 May 2024 14:47:18 GMT, Stefan Karlsson 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: References: 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: References: Message-ID: On Mon, 13 May 2024 10:17:57 GMT, Stefan Karlsson 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: References: <08rpfgXgTS5RvsqbnwgKdUKo3ADDDGuieSJclVz7leg=.28cded8e-3d2e-4fab-92f6-be89f7ddc6ce@github.com> Message-ID: On Mon, 13 May 2024 15:53:26 GMT, Leonid Mesnik 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: On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik 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: References: Message-ID: <3LosTENVEPXiSEynSv-6wDNR_ces65ID9d0AuVJQ9MY=.b8481fb0-1c6c-4873-b538-f48240595863@github.com> On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov 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: References: Message-ID: On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov 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: References: Message-ID: On Mon, 13 May 2024 21:08:08 GMT, Evgeny Astigeevich 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: <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com> Message-ID: On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe 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: <-CWxZnLMZoA9GeqM-hJ8m2d8-HWDQ7bVRhoWbf80MTE=.e77cd29b-70f9-4732-b04c-12a333bc559c@github.com> Message-ID: On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe 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: References: Message-ID: On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe 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 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> Message-ID: On Fri, 3 May 2024 10:42:45 GMT, Serguei Spitsyn 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: References: Message-ID: > 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: On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik 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: On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo 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 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: On Tue, 14 May 2024 22:19:19 GMT, Leonid Mesnik 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> Message-ID: On Tue, 14 May 2024 17:51:03 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> Message-ID: On Tue, 14 May 2024 23:13:28 GMT, Serguei Spitsyn 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Thu, 2 May 2024 21:50:26 GMT, Chris Plummer wrote: >> src/java.se/share/data/jdwp/jdwp.spec line 1622: >> >>> 1620: (threadObject owner "The platform thread owning this monitor, or nullptr " >>> 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:45:58 GMT, Chris Plummer 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: > 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: 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: 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: References: Message-ID: On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore 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: References: Message-ID: On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman 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: References: Message-ID: On Fri, 10 May 2024 22:09:01 GMT, Daniel D. Daugherty 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: 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: References: Message-ID: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com> On Wed, 15 May 2024 00:54:43 GMT, David Holmes 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: References: Message-ID: On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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: References: Message-ID: <9DAxT7CKkwfO--15Kj-GliNuij4f8oQuijqtdxaG-3k=.50b04ca8-07ce-44ae-afdc-01e3b31d9344@github.com> On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore 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: References: 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: 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: <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: 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: References: Message-ID: <_MDZPWLFa7qcrmsqMsXDJx6Y5lqfI3E4d6Z6-VKv79g=.ad216d38-b066-47d2-bfcd-31a64052015d@github.com> On Wed, 15 May 2024 07:55:27 GMT, ExE Boss 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: References: Message-ID: On Mon, 13 May 2024 22:43:44 GMT, Vladimir Kozlov 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: References: Message-ID: On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich 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 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: <-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 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: References: Message-ID: > 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: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com> <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com> Message-ID: On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore 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: References: Message-ID: On Thu, 9 May 2024 07:50:00 GMT, Julian Waters 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: References: Message-ID: On Thu, 9 May 2024 07:50:00 GMT, Julian Waters 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 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 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: References: Message-ID: On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore 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: References: Message-ID: > 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: 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: References: Message-ID: On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls 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: References: Message-ID: On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls 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: References: Message-ID: On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 14 May 2024 00:44:44 GMT, Alex Menkov 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 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> <2A25kL9oqh30aBRofiekO9CwmSwgEZ5LEcReUEfmxrQ=.eec2eaf8-dc9a-4a0d-bb42-d9f192f72fb2@github.com> <2lhm2l4CzUnyStTj215njaZg9EcMwwKWxMxtdZTXD8I=.ba8b1275-f16c-4af4-80e5-81ace9b40aa2@github.com> Message-ID: On Tue, 14 May 2024 23:19:14 GMT, Serguei Spitsyn 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 1 May 2024 20:49:02 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Tue, 14 May 2024 23:56:14 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 15 May 2024 17:49:07 GMT, Daniel Fuchs 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: > 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 15 May 2024 19:51:51 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 15 May 2024 19:52:36 GMT, Chris Plummer 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: References: Message-ID: On Wed, 15 May 2024 19:09:54 GMT, Chris Plummer 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: > 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: References: Message-ID: On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: <0YzEv8zaHhoN7u7Iq8xN63266pMnnpGAeC-UkAbWLtg=.eb8764d0-fe4e-4bb2-895b-aaf3c97f5f85@github.com> On Wed, 15 May 2024 20:09:52 GMT, Serguei Spitsyn 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls 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: References: Message-ID: On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: Message-ID: On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: Message-ID: On Wed, 15 May 2024 21:20:25 GMT, Chris Plummer 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: References: <-lAT5GzHVRrOUJhhMLfV5CkkPA3DHHDUZfdE7CBOcHg=.ecb91a2d-82c2-4e94-a1f6-f84d7a8c2a87@github.com> Message-ID: On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls 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: References: Message-ID: <5b211vTNYsdE-dj-PdfDkrw1UGAit9OVXUnxQ0nudCs=.d8382b7b-31ac-4388-8eba-eaf2558f7969@github.com> On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: Message-ID: On Wed, 15 May 2024 21:38:54 GMT, Kevin Walls 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: References: Message-ID: On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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: 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: References: Message-ID: On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai 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 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: References: Message-ID: <4QTrXORVLmXOdBxVAdYyAE9M7HTfxOjcW0NVtitY-og=.aef997d7-96d6-4992-b308-d951046c920f@github.com> On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn 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 nullptr which is C programming language > 1008: null 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: References: Message-ID: On Wed, 15 May 2024 23:40:00 GMT, Chris Plummer 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: References: Message-ID: <8VfBzZdiXsFsNs9s-TbP9pFAxUTBpjGVyicTU-oesK8=.63a74189-cce2-4baa-bfb6-7eb79909c017@github.com> On Wed, 15 May 2024 22:44:03 GMT, Serguei Spitsyn 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: References: Message-ID: On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls 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: References: Message-ID: On Thu, 16 May 2024 09:40:58 GMT, Daniel Fuchs 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: References: Message-ID: On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls 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: References: Message-ID: On Thu, 16 May 2024 10:26:25 GMT, Daniel Fuchs 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: References: Message-ID: On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: <2MTpDdv0J0zKzTV3vhzt-_RjO7oNA9ih7rnPIlmnPbY=.a1a7e975-1289-4ea4-a377-f71684a0407c@github.com> Message-ID: On Mon, 13 May 2024 19:30:31 GMT, Nizar Benalla 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: On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla 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 Committer: Jaikiran Pai 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: References: Message-ID: On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore 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: \ 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: References: Message-ID: On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls 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 names or * filters is null, or if names 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: References: Message-ID: On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore 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: References: Message-ID: > 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: References: Message-ID: On Thu, 16 May 2024 11:38:28 GMT, Daniel Fuchs wrote: >> Yes, completely understand. I just don't think it has any benefit. > > Hmmm... the spec still says: > > * @throws IllegalArgumentException if names or > * filters is null, or if names 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: References: Message-ID: On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai 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: \ 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: References: Message-ID: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com> On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore 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: \ 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: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com> Message-ID: On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai 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: References: Message-ID: > 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: References: Message-ID: <9MCc5CH-ddXg3f6pPVB59p4FF49OvZc8l4sktT4mqLY=.e30a0f9c-d014-4325-b77b-299cb7384c99@github.com> On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: Message-ID: On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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: References: Message-ID: <--X2yEIBcHf36UAqIcn04d9QNyzHdXmP9oz8hlyfWHQ=.17c793e1-2b6a-4580-a34f-3a0863f96c53@github.com> On Thu, 16 May 2024 11:00:33 GMT, Johan Sj?len 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: On Thu, 16 May 2024 15:31:15 GMT, Chris Plummer 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: On Thu, 16 May 2024 15:31:15 GMT, Chris Plummer 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: References: Message-ID: On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore 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: References: Message-ID: On Thu, 16 May 2024 07:57:58 GMT, Alan Bateman 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 nullptr which is C programming language >> 1008: null 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: References: Message-ID: <1riS2rxi8S3odLFxNcMLJloR00dRiKKpEQnd7uIGxEw=.590cba72-b756-4bab-9522-59ff0613140b@github.com> On Wed, 15 May 2024 06:00:46 GMT, Serguei Spitsyn 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: References: Message-ID: On Thu, 16 May 2024 11:46:30 GMT, Kevin Walls 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: * NotificationFilters. 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 names or > 968: * filters is null, or if names 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: References: 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: References: Message-ID: On Thu, 16 May 2024 19:53:48 GMT, Sean Mullan 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: * NotificationFilters. 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 names or >> 968: * filters is null, or if names 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: References: Message-ID: On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn 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 nullptr which is C programming language > 1008: null pointer. Perhaps instead something like "returned as a null pointer (C NULL or C++ nullptr)." "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: References: 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: References: Message-ID: On Thu, 16 May 2024 07:59:51 GMT, Kim Barrett 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 nullptr which is C programming language >> 1008: null pointer. > > Perhaps instead something like > > "returned as a null pointer (C NULL or C++ nullptr)." > > "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: References: Message-ID: On Thu, 16 May 2024 19:26:07 GMT, Chris Plummer wrote: >> src/hotspot/share/prims/jvmti.xml line 1008: >> >>> 1006: function descriptions. Empty lists, arrays, sequences, etc are >>> 1007: returned as nullptr which is C programming language >>> 1008: null 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: 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: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com> Message-ID: On Fri, 17 May 2024 00:43:18 GMT, Serguei Spitsyn 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: <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 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 nullptr 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: References: Message-ID: > 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: <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 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 > 1006: function descriptions. Empty lists, arrays, sequences, etc are > 1007: returned as a null pointer (C NULL or C++ nullptr). 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: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com> <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com> Message-ID: On Fri, 17 May 2024 02:00:29 GMT, David Holmes 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 nullptr > ``` > > 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: References: Message-ID: On Fri, 17 May 2024 00:38:07 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 1008: >> >>> 1006: function descriptions. Empty lists, arrays, sequences, etc are >>> 1007: returned as nullptr which is C programming language >>> 1008: null pointer. >> >> Perhaps instead something like >> >> "returned as a null pointer (C NULL or C++ nullptr)." >> >> "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: References: Message-ID: On Fri, 17 May 2024 02:08:34 GMT, Leonid Mesnik 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: References: Message-ID: On Fri, 10 May 2024 08:55:36 GMT, Albert Mingkun Yang 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: References: Message-ID: On Fri, 17 May 2024 06:02:31 GMT, Ivan Walulya 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: References: Message-ID: <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com> On Fri, 17 May 2024 07:17:13 GMT, Albert Mingkun Yang 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: References: Message-ID: > 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: <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com> Message-ID: On Fri, 17 May 2024 07:22:36 GMT, Ivan Walulya 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: References: <3BLe1vEaprqbbs1Qa2dFYzxOJ3YDdIAC6XVC-R5fgbg=.2c8bab90-0c18-4c33-a343-6667ff2f92ec@github.com> Message-ID: On Fri, 17 May 2024 07:39:39 GMT, Albert Mingkun Yang 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: References: Message-ID: On Fri, 17 May 2024 07:44:29 GMT, Albert Mingkun Yang 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: References: Message-ID: On Fri, 17 May 2024 07:44:29 GMT, Albert Mingkun Yang 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: References: 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 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 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: References: Message-ID: <9oh0XZoux2OKBke0T-hr6CS9OsuDD6Wk1HdQdPu2YyY=.1d9a2a75-cb80-498c-86f9-da457669e3e8@github.com> On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore 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 illegal. 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: References: Message-ID: On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore 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: References: Message-ID: On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin 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 Committer: Aleksey Shipilev 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: References: Message-ID: On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore 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: References: Message-ID: On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore 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: <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 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: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com> Message-ID: On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls 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: References: Message-ID: On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman 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: References: Message-ID: > 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: References: 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: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com> <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com> Message-ID: On Fri, 17 May 2024 10:14:43 GMT, Daniel Fuchs 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: References: Message-ID: > 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: References: Message-ID: On Fri, 17 May 2024 05:52:36 GMT, David Holmes 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: > 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <4_8gwr-HABvjvG9bTHSyQZs79DxHFr1wgqlzcl8PhXI=.be19c683-e4eb-4129-8e03-a9bf52e002e1@github.com> Message-ID: On Thu, 16 May 2024 17:37:30 GMT, Kevin Walls 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com> On Thu, 2 May 2024 20:58:27 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: <-Ho-NMofYJzkvKpfdUrOOq0RqLamcGGtrSm3MFy2cIs=.d3b334f2-0d6c-4e77-b91c-63a463790e28@github.com> On Thu, 9 May 2024 06:10:04 GMT, Chris Plummer 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: References: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com> <_CuYvr39rfebBcJRO0AM-2p8yQ2-V0oboFclyxAJ7Mo=.8cdba311-3f93-4c95-ac8b-6d7d41d88e24@github.com> Message-ID: On Fri, 17 May 2024 04:34:22 GMT, Kim Barrett 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: References: Message-ID: > 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> <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com> Message-ID: On Fri, 17 May 2024 19:52:00 GMT, Alex Menkov 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> <-Ho-NMofYJzkvKpfdUrOOq0RqLamcGGtrSm3MFy2cIs=.d3b334f2-0d6c-4e77-b91c-63a463790e28@github.com> Message-ID: On Fri, 17 May 2024 20:03:11 GMT, Alex Menkov 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: 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> <28NexB9cqJOSLsSmeTr8XkIIoZcgffhI6GUWaGalSg4=.717051ce-33f9-4a30-967e-1b1f37635afa@github.com> Message-ID: <0HXJPQWdMRSKIcTjYTovSy7Gybekqpga4xQ55Lwc8c4=.57042c01-8bae-4d43-bfe7-e7b1238913e9@github.com> On Fri, 17 May 2024 22:56:25 GMT, Chris Plummer 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: > 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: References: Message-ID: <_4CgX7Ojzb5QH2sJ4k2fDgfz_zba03l_4feYaVyzhl0=.a6128ce8-56c3-4b71-a0e3-cf48c9b68c3e@github.com> On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore 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: 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: References: Message-ID: On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla 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: References: Message-ID: On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla 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: References: Message-ID: On Sun, 19 May 2024 18:47:50 GMT, Alan Bateman 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: References: Message-ID: On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 20 May 2024 01:47:31 GMT, David Holmes 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: References: Message-ID: On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 20 May 2024 03:23:25 GMT, Chris Plummer 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: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Mon, 20 May 2024 04:25:49 GMT, David Holmes 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: References: Message-ID: On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik 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: References: Message-ID: <6zDrA0b4meB2PNnopX2wSHm3HFBCPScHj4PjBInaF5M=.d8a1e42b-f975-41c0-960c-85e53debb57a@github.com> On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls 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: References: Message-ID: On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla 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: References: Message-ID: On Sun, 19 May 2024 19:05:19 GMT, Nizar Benalla 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 `` with `{@code }` and `
` 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: 
References: 
 
 
 
 
Message-ID: 

On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls  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: 
References: 
 
Message-ID: 

On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik  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: 
References: 
Message-ID: 

> 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: 
References: 
 
 
 
Message-ID: <4ssnCnWfoNweZzRT3W2sfYKq1ojEZLWMX15dyyUTBVY=.b42fb343-2d21-4d32-9a80-4f6fb82aa192@github.com>

On Mon, 20 May 2024 13:19:37 GMT, Daniel Fuchs  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 `` with `{@code }` and `
` 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: 
References: 
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: 
References: 
 
Message-ID: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>

On Mon, 13 May 2024 10:49:30 GMT, Maurizio Cimadamore  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: 
References: 
 
Message-ID: 

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore  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: 
 
 <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
Message-ID: 

On Mon, 20 May 2024 18:39:31 GMT, Phil Race  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: 
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
Message-ID: 

On Mon, 20 May 2024 18:15:16 GMT, Nizar Benalla  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: 
References: 
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 
Message-ID: 

On Mon, 20 May 2024 18:50:08 GMT, Roger Riggs  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: 
References: 
Message-ID: 

> 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: 
References: 
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 
Message-ID: 

On Mon, 20 May 2024 18:52:58 GMT, Roger Riggs  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: 
References: 
 <0VHR6KjogwNekvL_J3QTvXOYrbutxqC4Q52S5OXYgbY=.82e3d272-4f28-49e5-85f2-2f1919f77d92@github.com>
 
 
Message-ID: 

On Mon, 20 May 2024 19:01:47 GMT, Nizar Benalla  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: 
References: 
Message-ID: 

> 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: 
References: 
Message-ID: 

On Sat, 18 May 2024 00:47:59 GMT, Alex Menkov  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: 
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 
Message-ID: <27qGzorWxtdq6HLmIMPLHZ6_qRbOZo2DvA7pewZfNKA=.3f11daeb-1645-466e-b4bb-56aab62021b2@github.com>

On Sat, 18 May 2024 09:07:18 GMT, Lei Zaakjyu  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: 
References: 
 
 
Message-ID: 

On Mon, 20 May 2024 18:47:35 GMT, Phil Race  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: 
References: 
 
 
 
Message-ID: 

On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman  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: 
References: 
 
Message-ID: 

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore  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: 
References: 
 
Message-ID: <2sHuToXAXHYrqtE31r7-wDvJ3JM0nQYujuLFAtqWQQI=.3c61631b-ecb1-4073-9b5f-6a379ab614cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore  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: 
 
 
 <5jtxG7mdbPDU7_iroUJP04Kut6e7o1_5XF2Ht_L9ciE=.67b51646-bcab-4fe8-a192-9d8e63a3e31b@github.com>
Message-ID: 

On Sun, 12 May 2024 18:38:34 GMT, 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. 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: 
References: 
 
 
 
 
Message-ID: 

On Tue, 21 May 2024 08:44:47 GMT, Maurizio Cimadamore  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: 
References: 
Message-ID: 

> 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: 
References: 
 
 
Message-ID: 

On Mon, 6 May 2024 18:31:06 GMT, Larry Cable  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 
>> . 
>> 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.
>>
>> ?
>> Reply to this email directly, view it on GitHub 
>>