From duke at openjdk.org Thu Jan 1 07:52:01 2026 From: duke at openjdk.org (Eunbin Son) Date: Thu, 1 Jan 2026 07:52:01 GMT Subject: Integrated: 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 09:55:58 GMT, Eunbin Son wrote: > ### Summary > Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported". > > ### Description > Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported". > > ### Bug ID : JDK-8374373 > https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373 This pull request has now been integrated. Changeset: 752f46d6 Author: Eunbin Son Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/752f46d66250dd44e1b13bbdbd86c70a33be3ac2 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29002 From lmesnik at openjdk.org Thu Jan 1 20:04:10 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 1 Jan 2026 20:04:10 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v4] In-Reply-To: References: Message-ID: <3I1JkYgdEAbWKlIXLRp06aicDkVTTS7WXEzBHCvJAwA=.d32d6420-ec94-4960-90f2-8412a81d0ab7@github.com> On Tue, 30 Dec 2025 23:20:34 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Add check for different addresses Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp line 56: > 54: } > 55: > 56: printf(": name: %s, code: 0x%016" PRIxPTR "\n", name, (uintptr_t)code_addr); I recommend to use "jvmti_common.hpp" Use `LOG()` to print messages, `fatal()` to fail test. Also, there are methods, like `get_method_name` that checks error code. ------------- PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3622028999 PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2656580219 From lmesnik at openjdk.org Thu Jan 1 20:04:12 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 1 Jan 2026 20:04:12 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v2] In-Reply-To: References: <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com> Message-ID: On Tue, 30 Dec 2025 23:17:20 GMT, Chad Rakoczy wrote: >> test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 188: >> >>> 186: WHITE_BOX.deoptimizeAll(); >>> 187: >>> 188: while (true) { >> >> It would be better to have some variable that is set in 'callbackCompiledMethodUnload' to sync exit. >> I think that it is more reliable then using stdout for this (even with flushing). >> However, it might be fixed later, if we find any issues with current version. > > I agree I don't think we should rely on stdout. I updated the test so all the event checking happens in the agent, and I kept some of the logging for debugging. Thank for moving logic into test process. I wonder if separate process is needed at all now? Might be it is possible to eliminate `ProcessTools.createTestJavaProcessBuilder(` and just do ll checks in the test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2656577743 From fandreuzzi at openjdk.org Fri Jan 2 11:56:23 2026 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 2 Jan 2026 11:56:23 GMT Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad Message-ID: I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it. ------------- Commit messages: - remove dot Changes: https://git.openjdk.org/jdk/pull/29017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29017&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374465 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29017/head:pull/29017 PR: https://git.openjdk.org/jdk/pull/29017 From kbarrett at openjdk.org Fri Jan 2 12:27:52 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 12:27:52 GMT Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi wrote: > I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29017#pullrequestreview-3623040745 From fandreuzzi at openjdk.org Fri Jan 2 12:40:00 2026 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 2 Jan 2026 12:40:00 GMT Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi wrote: > I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it. Failure looks unrelated: https://github.com/fandreuz/jdk/actions/runs/20657192979/job/59312268923#step:9:6386 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29017#issuecomment-3705242964 From fandreuzzi at openjdk.org Fri Jan 2 14:54:03 2026 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 2 Jan 2026 14:54:03 GMT Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 12:23:48 GMT, Kim Barrett wrote: >> I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it. > > Looks good, and trivial. Thanks for the review @kimbarrett. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29017#issuecomment-3705518190 From fandreuzzi at openjdk.org Fri Jan 2 14:54:05 2026 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 2 Jan 2026 14:54:05 GMT Subject: Integrated: 8374465: Spurious dot in documentation for JVMTI ClassLoad In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi wrote: > I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it. This pull request has now been integrated. Changeset: 2daf12ed Author: Francesco Andreuzzi URL: https://git.openjdk.org/jdk/commit/2daf12edd24e641d4d7706d582994c2b3fe95e87 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29017 From ysuenaga at openjdk.org Fri Jan 2 15:39:31 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 2 Jan 2026 15:39:31 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows Message-ID: When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: ----------------- 4 ----------------- "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] java.lang.Thread.State: TIMED_WAITING (sleeping) JavaThread state: _thread_blocked 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 ----------------- 5 ----------------- This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). We cannot depend on base pointer to unwind call frames, but SA do that. This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. This change passed serviceability/sa tests on Windows 11. ------------- Commit messages: - 8374469: Mixed jstack does not work on Windows Changes: https://git.openjdk.org/jdk/pull/29019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374469 Stats: 138 lines in 6 files changed: 109 ins; 2 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Sat Jan 3 13:31:44 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 3 Jan 2026 13:31:44 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack Message-ID: SA does not handle signal handler frame in mixed jstack as following: ----------------- 1789 ----------------- "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f6551c0e735 __GI_abort + 0x8b 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 0x00007f6551c27290 ???????? 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) 0x00007f6534000849 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 0x00007f6551e0582d JavaMain + 0xe4d 0x00007f6551c7f464 start_thread + 0x2e4 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). It should be like following: 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a 0x00007fdbd267b290 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) This is long standing bug (since JDK 9 at least). ------------- Commit messages: - 8374482: SA does not handle signal handler frame in mixed jstack Changes: https://git.openjdk.org/jdk/pull/29023/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374482 Stats: 163 lines in 4 files changed: 153 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From lmesnik at openjdk.org Sat Jan 3 19:52:27 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 3 Jan 2026 19:52:27 GMT Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires Message-ID: Remove group :serviceability_ttf_virtual and mark only failing tests with requires. ------------- Commit messages: - updated tests Changes: https://git.openjdk.org/jdk/pull/29024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374483 Stats: 52 lines in 19 files changed: 26 ins; 7 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29024/head:pull/29024 PR: https://git.openjdk.org/jdk/pull/29024 From serb at openjdk.org Sun Jan 4 02:20:09 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 4 Jan 2026 02:20:09 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Mon, 10 Nov 2025 22:24:52 GMT, Archie Cobbs wrote: >> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. >> >> Summary of code changes: >> >> * Add new warning and associated lint category `"suppression"` >> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? >> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. >> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. >> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. >> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break >> >> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: > > - Suppress new unnecessary suppresion warnings created by recent commits. > - Merge branch 'master' into JDK-8344159 > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflicts. > - Add clarifying comment. > - Merge branch 'master' into JDK-8344159 > - Change inner class name to avoid shadowing superclass name. > - Add a couple of code clarification comments. > - Refactor test to avoid requiring changes to TestRunner. > - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 Is this PR still active, or is there any ongoing work on it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3707541329 From syan at openjdk.org Sun Jan 4 02:41:05 2026 From: syan at openjdk.org (SendaoYan) Date: Sun, 4 Jan 2026 02:41:05 GMT Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires In-Reply-To: References: Message-ID: <-sYToet_Qr8ddZAeRXW_5HoEJqfwCYNcWm0myfHVO-w=.a4955764-1b19-450c-b1cd-ca71d74376d0@github.com> On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik wrote: > Remove group :serviceability_ttf_virtual and mark only failing tests with requires. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29024#pullrequestreview-3624638135 From ysuenaga at openjdk.org Sun Jan 4 05:29:58 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 4 Jan 2026 05:29:58 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Fix split pattern for Windows - Tweak toFrame() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/32053860..d34dfa1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=00-01 Stats: 8 lines in 2 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From acobbs at openjdk.org Sun Jan 4 16:27:07 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 16:27:07 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Sun, 4 Jan 2026 02:17:35 GMT, Sergey Bylokhov wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Suppress new unnecessary suppresion warnings created by recent commits. >> - Merge branch 'master' into JDK-8344159 >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Add clarifying comment. >> - Merge branch 'master' into JDK-8344159 >> - Change inner class name to avoid shadowing superclass name. >> - Add a couple of code clarification comments. >> - Refactor test to avoid requiring changes to TestRunner. >> - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 > > Is this PR still active, or is there any ongoing work on it? Hi @mrserb, > Is this PR still active, or is there any ongoing work on it? Work is completed to the point that it's ready for review, but this is a new feature and as such is lower priority than other changes that are currently being worked on. In the meantime if you're interested in doing any testing or playing around with it I'd love to hear any feedback. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3708223841 From acobbs at openjdk.org Sun Jan 4 18:04:45 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 18:04:45 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v6] In-Reply-To: References: Message-ID: <6hvrmK7tyWXAYYeJoCF9jP68LEShyo45T3vo3o7eF2U=.a8c1af86-8025-447e-b531-d195409e3117@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 139 commits: - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Add clarifying comment. - ... and 129 more: https://git.openjdk.org/jdk/compare/53824cf2...cad270ed ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=05 Stats: 1695 lines in 35 files changed: 1492 ins; 49 del; 154 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From ysuenaga at openjdk.org Mon Jan 5 00:06:58 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 5 Jan 2026 00:06:58 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v4] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 14:47:40 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Improve exception PING: Can I get Reviewer? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3708553408 From syan at openjdk.org Mon Jan 5 14:08:32 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 5 Jan 2026 14:08:32 GMT Subject: [jdk26] Withdrawn: 8373127: Update nsk/monitoring tests to support virtual thread factory testing In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 09:23:32 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [b0f59f60](https://github.com/openjdk/jdk/commit/b0f59f6021a00dc569e08810b34db21553a5b68d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Leonid Mesnik on 6 Dec 2025 and was reviewed by Kevin Walls and Alex Menkov. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28695 From amenkov at openjdk.org Mon Jan 5 20:01:18 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 5 Jan 2026 20:01:18 GMT Subject: Integrated: 8374168: Resolve disabled warnings in JDWP agent In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com> References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com> Message-ID: On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov wrote: > The fix resolves disabled warnings in debugger agent This pull request has now been integrated. Changeset: fa8ea6b3 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/fa8ea6b32d463a84affa529d37cfb97280503fc6 Stats: 65 lines in 11 files changed: 19 ins; 33 del; 13 mod 8374168: Resolve disabled warnings in JDWP agent Reviewed-by: cjplummer, sspitsyn, erikj ------------- PR: https://git.openjdk.org/jdk/pull/28937 From duke at openjdk.org Mon Jan 5 20:25:48 2026 From: duke at openjdk.org (Larry Cable) Date: Mon, 5 Jan 2026 20:25:48 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process Message-ID: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. effectively: someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() (where interim oops are null-checked) ------------- Commit messages: - JDK-8327246: Add a jcmd diagnostic command to list the jar files loaded by a process Changes: https://git.openjdk.org/jdk/pull/29048/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327246 Stats: 49 lines in 4 files changed: 41 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From duke at openjdk.org Mon Jan 5 21:11:00 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Mon, 5 Jan 2026 21:11:00 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v5] In-Reply-To: References: Message-ID: > [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) > > The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision: - Use jvmti_common functions - Remove seperate process ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28683/files - new: https://git.openjdk.org/jdk/pull/28683/files/cd023c3a..337c94b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=03-04 Stats: 128 lines in 2 files changed: 52 ins; 46 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/28683.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28683/head:pull/28683 PR: https://git.openjdk.org/jdk/pull/28683 From sspitsyn at openjdk.org Mon Jan 5 21:12:14 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Jan 2026 21:12:14 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable wrote: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) I wonder if verbose parameter should cause to print class files location. Was this option considered, and if so then why has it been rejected? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712095241 From duke at openjdk.org Mon Jan 5 21:15:53 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Mon, 5 Jan 2026 21:15:53 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v2] In-Reply-To: References: <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com> Message-ID: On Thu, 1 Jan 2026 19:54:31 GMT, Leonid Mesnik wrote: >> I agree I don't think we should rely on stdout. I updated the test so all the event checking happens in the agent, and I kept some of the logging for debugging. > > Thank for moving logic into test process. I wonder if separate process is needed at all now? > Might be it is possible to eliminate > `ProcessTools.createTestJavaProcessBuilder(` > and just do ll checks in the test? It required coordinating shutdown with the agent (since an exit code of zero still causes the test to fail) but I managed to remove the separate process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2662818496 From serguei.spitsyn at oracle.com Mon Jan 5 21:54:21 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Mon, 5 Jan 2026 21:54:21 +0000 Subject: New JDK Committer: Larry Cable Message-ID: Voting [1] for Larry Cable is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the bylaw's definition of Lazy Consensus [2], this is sufficient to approve the nomination. Thanks, Serguei [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-December/010694.html [2] https://openjdk.org/bylaws#lazy-consensus -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Mon Jan 5 22:23:39 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 5 Jan 2026 22:23:39 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable wrote: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Changes requested by lmesnik (Reviewer). src/hotspot/share/services/diagnosticCommand.cpp line 962: > 960: "S = is shared class", > 961: "BOOLEAN", false, "false"), > 962: _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") { Not a review yet. But this new functionality deserve a regression test. ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3628602391 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2662962679 From duke at openjdk.org Mon Jan 5 23:25:55 2026 From: duke at openjdk.org (Larry Cable) Date: Mon, 5 Jan 2026 23:25:55 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 21:09:17 GMT, Serguei Spitsyn wrote: > I wonder if verbose parameter should cause to print class files location. Was this option considered, and if so then why has it been rejected? I typically avoid modifying the behavior (and hence o/p) of existing commands; in my view a particular command (and options etc) and the resulting o/p format are part of the API "contract", hence simply modifying the -verbose option to emit this additional field, would break the existing "contract", which in the case of a programmatic parser client would most likely cause failures. IMO adding a new option preserves the existing contract while providing the additional metadata for new consumers aware of its availability and desirous of its content. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712445113 From serguei.spitsyn at oracle.com Mon Jan 5 23:45:01 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Mon, 5 Jan 2026 23:45:01 +0000 Subject: Result: New Serviceability Group Member: Chris Plummer Message-ID: The vote for Chris Plummer [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Serguei [1] https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068588.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Jan 5 23:48:47 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Mon, 5 Jan 2026 23:48:47 +0000 Subject: Result: New Serviceability Group Member: Alex Menkov Message-ID: Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Serguei [1] https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068589.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Jan 5 23:54:42 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Mon, 5 Jan 2026 23:54:42 +0000 Subject: Result: New Serviceability Group Member: Kevin Walls Message-ID: The vote for Kevin Walls [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Serguei [1] https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068585.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Jan 5 23:57:52 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Mon, 5 Jan 2026 23:57:52 +0000 Subject: Result: New Serviceability Group Member: Leonid Mesnik Message-ID: The vote for Leonid Mesnik [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Serguei [1] https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068591.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Tue Jan 6 00:24:32 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Jan 2026 00:24:32 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v5] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 21:11:00 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision: > > - Use jvmti_common functions > - Remove seperate process Thanks for update. The test looks simpler and work faster now. Please find my inline comments related ro AttachCurrentThread usage. Here are some inline comments test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp line 39: > 37: * Helper function to update the shouldExit field in the Java test class. > 38: */ > 39: static void updateShouldExit() { The simpler and more usual way is to have native variable `static std::atomic should_exit;` and poke it from hava code with JNIEXPORT jboolean JNICALL java_..._shouldExitt(JNIEnv *env, jobject obj) { return should_exit.load(); } It is more compact and and simpler. Also, I am not sure if AttachCurrentThread supposed to work for NonJavaThread or VM-intrenal thread, like compiler thread. test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp line 116: > 114: > 115: // Only track events for "compiledMethod" > 116: char* name = get_method_name(jvmti, env, method); Can you please add new method `get_method_name(jvmti, method);` that uses `check_jvmti_error(jvmtiError err, const char* msg) ` and doesn't need JNI. So no need to use `AttachCurrentThread`. ------------- Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3628832754 PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3628833420 PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2663164281 PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2663167608 From dholmes at openjdk.org Tue Jan 6 00:52:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 00:52:44 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable wrote: > I typically avoid modifying the behavior (and hence o/p) of existing commands; in my view a particular command (and options etc) and the resulting o/p format are part of the API "contract", I think our position is that the output of these commands is not a contract and can be changed - it is treated as "diagnostic output" and so not subject to CSR requests. This allows the freedom to adjust/expand the output without being forced to add a new command or option to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712614167 From dholmes at openjdk.org Tue Jan 6 02:02:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:02:16 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed [v4] In-Reply-To: References: Message-ID: On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov wrote: >> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) >> >> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: >> >> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~ >> >> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into copy_hotspot > - 8374316: Update copyright year to 2025 for hotspot in files where it was missed Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3712798915 From dholmes at openjdk.org Tue Jan 6 02:24:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:24:41 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 08:48:15 GMT, SendaoYan wrote: >> Hi all, >> >> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests. >> >> Change has been verified locally. Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 87: > 85: public static void main(String[] args) throws Exception { > 86: Metrics m = Metrics.systemMetrics(); > 87: // If cgroups is not configured, report success Suggestion: // If cgroups is not configured, the test is skipped. test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > 371: long oldVal = metrics.getCpuPeriod(); > 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { > 373: System.out.println("Get cpu period fails, test skipped."); Note sure this indicates a "fail" as such. ------------- PR Review: https://git.openjdk.org/jdk/pull/28996#pullrequestreview-3629079111 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663353307 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663359000 From dholmes at openjdk.org Tue Jan 6 02:44:06 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:44:06 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation I'm not sure about the approach here. My understanding was that "bsd" covered both macOS and potentially other BSD derivatives, while "darwin" provided macOS specific code. You seem to be indicating that the existing "bsd" code only works for macOS and so have renamed it all. If so that is fine (though a little surprising), but then having "macos" and "darwin" as alternatives really makes no sense to me. ?? Also while we have become stuck with using "macosx" in many places in the code, if we can we should use macos/macOS here. ------------- PR Review: https://git.openjdk.org/jdk/pull/29003#pullrequestreview-3629112451 From sspitsyn at openjdk.org Tue Jan 6 02:45:38 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Jan 2026 02:45:38 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v5] In-Reply-To: References: Message-ID: <4cRjZst7BQ0wbyNLad-qy72Qn2qIGC2lNpFdQff2vHs=.29597aa7-c41d-49e4-919c-9d2a4bec6274@github.com> On Mon, 5 Jan 2026 21:11:00 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision: > > - Use jvmti_common functions > - Remove seperate process Changes requested by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3629094479 From sspitsyn at openjdk.org Tue Jan 6 02:45:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Jan 2026 02:45:41 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v5] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:18:50 GMT, Leonid Mesnik wrote: >> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use jvmti_common functions >> - Remove seperate process > > test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp line 39: > >> 37: * Helper function to update the shouldExit field in the Java test class. >> 38: */ >> 39: static void updateShouldExit() { > > The simpler and more usual way is to have native variable > `static std::atomic should_exit;` > and poke it from hava code with > > JNIEXPORT jboolean JNICALL > java_..._shouldExitt(JNIEnv *env, jobject obj) { > return should_exit.load(); > } > > It is more compact and and simpler. > Also, I am not sure if AttachCurrentThread supposed to work for NonJavaThread or VM-intrenal thread, like compiler thread. I'd suggest to introduce a native method `shouldExit()` which is called from java level and returns the `should_exit` value. It will be much simpler than the `updateShouldExit()` function implementation. > test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp line 116: > >> 114: >> 115: // Only track events for "compiledMethod" >> 116: char* name = get_method_name(jvmti, env, method); > > Can you please add new method > `get_method_name(jvmti, method);` > that uses > `check_jvmti_error(jvmtiError err, const char* msg) ` > and doesn't need JNI. > > So no need to use `AttachCurrentThread`. Good idea. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2663368888 PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2663386507 From syan at openjdk.org Tue Jan 6 02:52:18 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 02:52:18 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v5] In-Reply-To: References: Message-ID: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update comment "If cgroups is not configured, the test is skipped." which suggestion from @dholmes-ora Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/068b1591..8e2ee419 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From dholmes at openjdk.org Tue Jan 6 03:03:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 03:03:58 GMT Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires In-Reply-To: References: Message-ID: On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik wrote: > Remove group :serviceability_ttf_virtual and mark only failing tests with requires. This seems reasonable. None of the modified tests should be run on a virtual thread, even if the test itself will be testing some virtual thread functionality. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29024#pullrequestreview-3629167763 From syan at openjdk.org Tue Jan 6 03:04:21 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:04:21 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: <5qxuuuhHvgrHEPlLUV-O8Ngykq5lufQ5n_IbmXxeu0k=.65dc5916-245b-412b-a60f-1c0058464051@github.com> On Tue, 6 Jan 2026 02:19:32 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java > > test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > >> 371: long oldVal = metrics.getCpuPeriod(); >> 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { >> 373: System.out.println("Get cpu period fails, test skipped."); > > Note sure this indicates a "fail" as such. The `getCpuPeriod` call `getLongValue` to read property value from file /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us. The `getLongValue` will return CgroupSubsystem.LONG_RETVAL_UNLIMITED if it can not open the file. So I think it's better to skip this sub-test when there is no /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663425108 From syan at openjdk.org Tue Jan 6 03:08:51 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:08:51 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:21:44 GMT, David Holmes wrote: > A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. This PR use SkippedException instead of report test pass. It's unrelated to the subject, It just fix it by the way ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3712926235 From alanb at openjdk.org Tue Jan 6 07:54:40 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 07:54:40 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 00:49:14 GMT, David Holmes wrote: > I think our position is that the output of these commands is not a contract and can be changed - it is treated as "diagnostic output" and so not subject to CSR requests. This allows the freedom to adjust/expand the output without being forced to add a new command or option to do so. In time then one could imagine options to these comments to produce structured text (probably JSON) that is intended to be parsed. We have this with Thread.dump_to_file where the output can be plain text or a JSON object. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3713559830 From kevinw at openjdk.org Tue Jan 6 10:54:38 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Jan 2026 10:54:38 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable wrote: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) src/hotspot/share/services/diagnosticCommand.cpp line 962: > 960: "S = is shared class", > 961: "BOOLEAN", false, "false"), > 962: _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") { Nit: "Print class.." the option descriptions all begin with capital letters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2664517932 From kevinw at openjdk.org Tue Jan 6 11:53:53 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Jan 2026 11:53:53 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable wrote: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) "VM.classes -verbose" is _very_ verbose already, so a separate option looks like the right choice to me. More lightweight queries for just this info. $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes | wc -l 544 $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes -verbose | wc -l 18209 (on a trivial test app) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3714418866 From kevinw at openjdk.org Tue Jan 6 12:25:04 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Jan 2026 12:25:04 GMT Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor error messages for better clarity [v2] In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 09:38:10 GMT, Eunbin Son wrote: >> ### Summary >> MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)". >> >> This addresses the first of three issues in JDK-8374395. >> >> ### Description >> When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this. >> >> toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged. >> >> Added test cases to the existing jtreg test file. All tests pass. >> >> ### Bug-ID : JDK-8374395 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395 > > Eunbin Son has updated the pull request incrementally with one additional commit since the last revision: > > 8374395: Add JUnit test for MemoryUsage.toString() undefined values > When `init` or `max` is `-1` (undefined), `MemoryUsage.toString()` outputs `"-1(-1K)"`, which is confusing. While Javadoc states that `-1` means undefined, the output does not clearly indicate this, making it difficult for users to distinguish undefined values from actual negative values. Hi. When does this happen? When is a MemoryUsage created with init or max as -1 ? When is it then printed using toString() for a user to understand, and when would the user then have to distinguish between the -1 which suggests a problem, and "actual negative values"? ------------- PR Review: https://git.openjdk.org/jdk/pull/29009#pullrequestreview-3630703891 From haraldei at openjdk.org Tue Jan 6 12:40:12 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Tue, 6 Jan 2026 12:40:12 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:39:08 GMT, David Holmes wrote: > My understanding was that "bsd" covered both macOS and potentially other BSD derivatives, while "darwin" provided macOS specific code. Yes, traditionally it seems the OS X port was grown from the BSD port, but have since diverged significantly. In the BSD port maintained out of tree, a lot of the code under the `bsd` directories are essentially split by `#ifdef`'s where the OS X and BSD code are almost entirely separate, and the BSD code is synced with, and more closely resembles the Linux code. > You seem to be indicating that the existing "bsd" code only works for macOS and so have renamed it all. The BSD code was broken in commit d3083ac05453c, and in trying to figure out how to fix it again it seemed easier to split the two implementations than to try to force them to coexist. This way the platforms would have less risk of breaking each others implementations. > If so that is fine (though a little surprising), but then having "macos" and "darwin" as alternatives really makes no sense to me. ?? I can rename it to darwin instead, if you feel that is better. It seemed like "macosx" was more established when I looked around the source tree, but I'm happy to adapt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3714552414 From lmesnik at openjdk.org Tue Jan 6 15:53:23 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Jan 2026 15:53:23 GMT Subject: Integrated: 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires In-Reply-To: References: Message-ID: On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik wrote: > Remove group :serviceability_ttf_virtual and mark only failing tests with requires. This pull request has now been integrated. Changeset: c611da25 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/c611da257f69e9c9b178b85cb705a4b0a42545ac Stats: 52 lines in 19 files changed: 26 ins; 7 del; 19 mod 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires Reviewed-by: syan, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29024 From kevinw at openjdk.org Tue Jan 6 19:30:01 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Jan 2026 19:30:01 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 23:53:39 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has updated the pull request incrementally with one additional commit since the last revision: > > 8374341: Update copyright year to 2025 for CoreUtils.java So that matching has never worked. 8-) But if we make this change, and it runs coredumpctl, does this now work as intended? I see "No journal files were opened due to insufficient permissions." from coredumpctl (but I didn't test during a test that creates a core). Another problem may be the unpredictability of the timing when files are large: the 5 second sleep and the 10 iterations. Is that always enough? Maybe this is fine, but if it has never actually been used, the code should be verified well before it's enabled. On my systems when a core dump pattern has the "|", I am familiar with seeing the message "This system uses a crash report tool.." from later in the file. It tells you the system is configured inappropriately, so you fix the pattern manually, and all is good. Maybe we should delete lines 168 to 191 and simply have that message at line 192 printed, and a test skipped, if a core file pattern using "|" is in place. ------------- PR Review: https://git.openjdk.org/jdk/pull/28984#pullrequestreview-3632198702 From cjplummer at openjdk.org Tue Jan 6 20:36:49 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Jan 2026 20:36:49 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation - The JDK libraries have macosx directories, although within java.base/macosx we also see files with Bsd in the name. - Hotspot has the os/bsd directory. I assume this is for both bsd and macosx. I don't see a macosx directory under src/hotspot. - SA has a macosx directory, although it is only for the native libsaproc. - SA also has a bsd directory, and a number files with bsd in the name, some of which are in the bsd directory and some that are not. - I don't see any files with "darwin" in the path or name, but maybe it is a more appropriate name in some cases. My conclusion is that this is all rather poorly thought out and very inconsistent. I don't yet have a suggestion on how to proceed. I just wanted to better describe where things are at now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3716226494 From dholmes at openjdk.org Tue Jan 6 21:20:37 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 21:20:37 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: <7RY770x8idjnbhLPr-btqU-nlvy72O9tlv47xHMZZqQ=.409f21a3-f066-4c2b-aa1c-2f54fd2647d7@github.com> On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation "darwin" seems to be mainly used within the SA code and it seems to be an alias for macOS/macosx - though why it was done that way I'm unsure. May be uname has "darwin" in it and so it is exposed via a system property? (Theoretically you could have a different OS built upon the XNU - aka Darwin - kernel, but we are not trying to support that in any way. I also see this in java_props_md.c ifdef MACOSX /* darwin has a per-user temp dir */ static char tmp_path[PATH_MAX]; int pathSize = confstr(_CS_DARWIN_USER_TEMP_DIR, tmp_path, PATH_MAX); if (pathSize > 0 && pathSize <= PATH_MAX) { sprops.tmp_dir = tmp_path; } #endif /* MACOSX */ Regardless it makes no sense to have macOS and Darwin supported by SA so some major renaming would also be needed there. The macosx naming is legacy from the days of the mac port when it was known as OS X. For a long time now it is just macOS but we didn't do a major renaming as that would be too disruptive. But if we are creating new files here then we can use the most appropriate naming scheme and not be caught up in legacy issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3716393460 From dholmes at openjdk.org Tue Jan 6 21:26:42 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 21:26:42 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation > The BSD code was broken in commit https://github.com/openjdk/jdk/commit/d3083ac05453c9dd303038f90ddab50d52124e51 Okay that is very recent - and very unfortunate. But as we don't know if/when the out-of-tree BSD port will come back into mainline, I would not want to see the existing BSD support effectively gone in JDK 27+. To that end we may need to look at specifically fixing what broke in that commit. Though the BSD specific changes there look innocuous to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3716402666 From duke at openjdk.org Tue Jan 6 21:29:36 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 6 Jan 2026 21:29:36 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/6ce88730..dd11893b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=00-01 Stats: 16 lines in 4 files changed: 3 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From duke at openjdk.org Tue Jan 6 21:35:25 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 6 Jan 2026 21:35:25 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 10:51:22 GMT, Kevin Walls wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments > > src/hotspot/share/services/diagnosticCommand.cpp line 962: > >> 960: "S = is shared class", >> 961: "BOOLEAN", false, "false"), >> 962: _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") { > > Nit: "Print class.." the option descriptions all begin with capital letters. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666360931 From duke at openjdk.org Tue Jan 6 21:35:26 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 6 Jan 2026 21:35:26 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 22:20:06 GMT, Leonid Mesnik wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments > > src/hotspot/share/services/diagnosticCommand.cpp line 962: > >> 960: "S = is shared class", >> 961: "BOOLEAN", false, "false"), >> 962: _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") { > > Not a review yet. But this new functionality deserve a regression test. noted.... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666362531 From duke at openjdk.org Tue Jan 6 21:43:39 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 6 Jan 2026 21:43:39 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 11:50:30 GMT, Kevin Walls wrote: > "VM.classes -verbose" is _very_ verbose already, so a separate option looks like the right choice to me. More lightweight queries for just this info. > > $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes | wc -l 544 $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes -verbose | wc -l 18209 (on a trivial test app) given the verbosity, its my inclination is to leave the impl as it is, with a distinct option flag for location, perhaps also adding it (location) if -verbose is specified (instead) ... for completeness. until such time as all jcmds support "human readable", & "machine parseable" formatting options I think that the small incremental effort required to maintain an albeit informal (and unsupported) contract here is worth it in the interim, I for one have no insight into what extent jcmd users depend on the current (plain text) formats as parseable but would prefer to avoid breaking any such assumptions for the price of an option flag (in moderation of course) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3716463122 From duke at openjdk.org Tue Jan 6 22:47:08 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 6 Jan 2026 22:47:08 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: > [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) > > The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Remove JNIenv use and update shouldExit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28683/files - new: https://git.openjdk.org/jdk/pull/28683/files/337c94b8..739de617 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28683&range=04-05 Stats: 94 lines in 3 files changed: 33 ins; 48 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28683.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28683/head:pull/28683 PR: https://git.openjdk.org/jdk/pull/28683 From dholmes at openjdk.org Wed Jan 7 00:05:18 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 7 Jan 2026 00:05:18 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments Overall approach seems reasonable. I have a couple of queries. Thanks src/hotspot/share/oops/instanceKlass.cpp line 2359: > 2357: // initialization state > 2358: > 2359: InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; Suggestion: InstanceKlass* ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; src/hotspot/share/oops/instanceKlass.cpp line 2386: > 2384: oop pd = java_lang_Class::protection_domain(k->java_mirror()); > 2385: > 2386: if (pd != nullptr && (ik = pd->klass()->is_instance_klass() ? InstanceKlass::cast(pd->klass()) : nullptr) != nullptr) { Is a non-instance-class possible here?? src/hotspot/share/oops/instanceKlass.cpp line 2397: > 2395: oop cs = pd->obj_field(csfd.offset()); > 2396: > 2397: if (cs != nullptr && (ik = cs->klass()->is_instance_klass() ? InstanceKlass::cast(cs->klass()) : nullptr) != nullptr) { Is a non-instance-class possible here?? src/hotspot/share/oops/instanceKlass.cpp line 2406: > 2404: oop loc = cs->obj_field(locfd.offset()); > 2405: > 2406: if (loc != nullptr && loc->klass() == vmClasses::String_klass()) { Why are you checking the class type? ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3632862000 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666611656 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666619018 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666619778 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666626257 From sspitsyn at openjdk.org Wed Jan 7 01:05:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 01:05:41 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <8iF5lwO870gPlfcozjDBwgYE9hw0WxeIjVfGiTT2ZmA=.a7b55428-5686-4578-b71a-f5d47414b524@github.com> On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable wrote: > IMO adding a new option preserves the existing contract while providing the additional metadata for new consumers aware of its availability and desirous of its content. I'm with this approach in general but just wanted opinions exchange on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3716914987 From sspitsyn at openjdk.org Wed Jan 7 01:19:17 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 01:19:17 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit Thank you for taking care about this issue and the updates! It looks good in general but I've posted one question. test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 108: > 106: while (!shouldExit()) { > 107: WHITE_BOX.fullGC(); > 108: } Q: Should we add a short sleep between calls to `WHITE_BOX.fullGC()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3633030135 PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2666756291 From duke at openjdk.org Wed Jan 7 02:11:15 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 7 Jan 2026 02:11:15 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 01:15:31 GMT, Serguei Spitsyn wrote: >> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove JNIenv use and update shouldExit > > test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 108: > >> 106: while (!shouldExit()) { >> 107: WHITE_BOX.fullGC(); >> 108: } > > Q: Should we add a short sleep between calls to `WHITE_BOX.fullGC()`? I think `WHITE_BOX.fullGC()` blocks until the GC completes so I'm not sure a sleep is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2666831479 From serb at openjdk.org Wed Jan 7 02:24:25 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 7 Jan 2026 02:24:25 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes wrote: >Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct. I tried to catch rename/move-only or copyright-only changes, but I?m not 100% sure I filtered all of them out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3717068454 From sspitsyn at openjdk.org Wed Jan 7 03:20:30 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 03:20:30 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v4] In-Reply-To: References: Message-ID: <91jC9ajf0mhxmgQignRJR5wG65YPJ3EnPsMD31KDQkw=.f1710749-f5ef-4c15-bb25-a68535976115@github.com> On Fri, 19 Dec 2025 14:47:40 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Improve exception This looks good in general. Thank you for fixing this! I've posted a couple of nits though. test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java line 3: > 1: /* > 2: * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2015, NTT DATA The Copyright year seems to be wrong? test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java line 84: > 82: "--enable-native-access=ALL-UNNAMED", > 83: String.format("-D%s=%s", EXPECTED_PROP_KEY, EXPECTED_PROP_VALUE), > 84: Debuggee.class.getName() The line 84 is not indented properly. I'd move it to line 83 as it is not that long. ------------- PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3633199224 PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2666919729 PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2666920968 From sspitsyn at openjdk.org Wed Jan 7 03:49:37 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 03:49:37 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 02:07:39 GMT, Chad Rakoczy wrote: >> test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 108: >> >>> 106: while (!shouldExit()) { >>> 107: WHITE_BOX.fullGC(); >>> 108: } >> >> Q: Should we add a short sleep between calls to `WHITE_BOX.fullGC()`? > > I think `WHITE_BOX.fullGC()` blocks until the GC completes so I'm not sure a sleep is necessary. Thanks. I'm okay with as it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2666969290 From sspitsyn at openjdk.org Wed Jan 7 03:49:37 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 03:49:37 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: <5JRD8nCTROjlpIlxJPW0MEOZFzHyUwz-4elmy1aEqPo=.0d1f1a17-5d5e-47b2-b50f-2a5da501a2f1@github.com> On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3633248716 From ysuenaga at openjdk.org Wed Jan 7 04:27:46 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 7 Jan 2026 04:27:46 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: > We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. > > > $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep > [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 > 2025-12-17 06:34:37 > Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): > > Threads class SMR info: > _java_thread_list=0x000078a8bc13f200, length=10, elements={ > 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, > 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, > : > > > Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). > > In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: > > > $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug > / # /usr/lib/jvm/jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded > at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > > / # ls -l /proc/1/cwd > ls: /proc/1/cwd: cannot read link: Permission denied > lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd > > > > After this change, we can see following exception on the console of jcmd when we encounter this situation: > > # jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm... Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Fix line - Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28867/files - new: https://git.openjdk.org/jdk/pull/28867/files/3341dd60..f8404d32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=03-04 Stats: 6 lines in 3 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28867/head:pull/28867 PR: https://git.openjdk.org/jdk/pull/28867 From ysuenaga at openjdk.org Wed Jan 7 04:27:51 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 7 Jan 2026 04:27:51 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v4] In-Reply-To: <91jC9ajf0mhxmgQignRJR5wG65YPJ3EnPsMD31KDQkw=.f1710749-f5ef-4c15-bb25-a68535976115@github.com> References: <91jC9ajf0mhxmgQignRJR5wG65YPJ3EnPsMD31KDQkw=.f1710749-f5ef-4c15-bb25-a68535976115@github.com> Message-ID: On Wed, 7 Jan 2026 03:14:34 GMT, Serguei Spitsyn wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve exception > > test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java line 3: > >> 1: /* >> 2: * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2015, NTT DATA > > The Copyright year seems to be wrong? Yes - I updated to 2026 in all of files. > test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java line 84: > >> 82: "--enable-native-access=ALL-UNNAMED", >> 83: String.format("-D%s=%s", EXPECTED_PROP_KEY, EXPECTED_PROP_VALUE), >> 84: Debuggee.class.getName() > > The line 84 is not indented properly. I'd move it to line 83 as it is not that long. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2667021404 PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2667021695 From ysuenaga at openjdk.org Wed Jan 7 05:00:52 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 7 Jan 2026 05:00:52 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME Message-ID: We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError heapdumponoutofmemoryerror This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. from-core On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . This change works fine with both interpreter and `-Xcomp`. ------------- Commit messages: - Follow current indy implementation in HotSpot - Fix getLocals() - Fix for InterpreterVFrame - Dump HPROF_GC_ROOT_JAVA_FRAME Changes: https://git.openjdk.org/jdk/pull/29058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374577 Stats: 65 lines in 4 files changed: 39 ins; 11 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29058/head:pull/29058 PR: https://git.openjdk.org/jdk/pull/29058 From lmesnik at openjdk.org Wed Jan 7 05:31:49 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 7 Jan 2026 05:31:49 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 09:47:21 GMT, Yasumasa Suenaga wrote: > We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. > > I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: > > > -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError > > > heapdumponoutofmemoryerror > > This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. > > from-core > > On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. > > heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. > > Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . > > This change works fine with both interpreter and `-Xcomp`. @YaSuenag Can you please add/update jtreg test for this fix or explain in the bug/PR why it is not added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3717371564 From ysuenaga at openjdk.org Wed Jan 7 06:09:19 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 7 Jan 2026 06:09:19 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: > We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. > > I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: > > > -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError > > > heapdumponoutofmemoryerror > > This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. > > from-core > > On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. > > heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. > > Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . > > This change works fine with both interpreter and `-Xcomp`. Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year in ConstantPool.java - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29058/files - new: https://git.openjdk.org/jdk/pull/29058/files/a9c9e6c9..12bb02db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29058&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29058&range=00-01 Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29058/head:pull/29058 PR: https://git.openjdk.org/jdk/pull/29058 From fyang at openjdk.org Wed Jan 7 06:59:48 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 7 Jan 2026 06:59:48 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Including test changes from Bhavana Kilambi (ARM) > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Fix failing jtreg test in CI > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d Hi, I have a minor question about the tests. test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: > 1891: VectorMask m = three.compare(VectorOperators.LE, higher); > 1892: assert(m.allTrue()); > 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3633583291 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667282723 From sspitsyn at openjdk.org Wed Jan 7 07:36:32 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 07:36:32 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3633670750 From ysuenaga at openjdk.org Wed Jan 7 08:24:51 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 7 Jan 2026 08:24:51 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 05:27:45 GMT, Leonid Mesnik wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > @YaSuenag Can you please add/update jtreg test for this fix or explain in the bug/PR why it is not added. @lmesnik I added the test to ClhsdbDumpheap.java whether `HPROF_GC_ROOT_JAVA_FRAME` is included in heap dump. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3717789768 From jbhateja at openjdk.org Wed Jan 7 09:05:47 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 Jan 2026 09:05:47 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Including test changes from Bhavana Kilambi (ARM) >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Optimizing tail handling >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Cleanups >> - Fix failing jtreg test in CI >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Cleanups >> - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d > > test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: > >> 1891: VectorMask m = three.compare(VectorOperators.LE, higher); >> 1892: assert(m.allTrue()); >> 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); > > I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667602759 From kevinw at openjdk.org Wed Jan 7 10:09:59 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 7 Jan 2026 10:09:59 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments src/hotspot/share/oops/instanceKlass.cpp line 2360: > 2358: > 2359: InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; > 2360: Looks good with the new local InstanceKlass ik. Is it possible to not reassign into ik at lines 2386 and 2397, i.e. ik was the target class as an instanceKlass, but later represents pd or cs, so that can be hard to follow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2667816732 From haraldei at openjdk.org Wed Jan 7 10:35:28 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Wed, 7 Jan 2026 10:35:28 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:20:29 GMT, David Holmes wrote: >> The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. >> >> This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. >> >> As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. >> >> This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. >> >> This work was sponsored by The FreeBSD Foundation > >> The BSD code was broken in commit https://github.com/openjdk/jdk/commit/d3083ac05453c9dd303038f90ddab50d52124e51 > > Okay that is very recent - and very unfortunate. But as we don't know if/when the out-of-tree BSD port will come back into mainline, I would not want to see the existing BSD support effectively gone in JDK 27+. To that end we may need to look at specifically fixing what broke in that commit. Though the BSD specific changes there look innocuous to me. @dholmes-ora > > The BSD code was broken in commit [d3083ac](https://github.com/openjdk/jdk/commit/d3083ac05453c9dd303038f90ddab50d52124e51) > > Okay that is very recent - and very unfortunate. Sure, but also not unexpected :) That's the life of an out-of-tree port. > But as we don't know if/when the out-of-tree BSD port will come back into mainline, I would not want to see the existing BSD support effectively gone in JDK 27+. It is in practice gone already, and has been for a long time. While the directories, files, classes and functions have "bsd" in them, they are in reality macOS sources. While some of it can be used unmodified on (some) other BSDs, most of it needs to be patched. So my idea was to move/rename this part that broke our port to better fit with reality, and then bring in the actual BSD code again in the BSD port. To me it feels cleaner, but I'll drop it if it's not wanted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3718247267 From lkorinth at openjdk.org Wed Jan 7 12:35:42 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:35:42 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: > > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings > > Reviewed-by: aboldtch > - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test > > Reviewed-by: serb, aivanov, dnguyen > - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 I will redo the merge, I have done something strange. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595 From duke at openjdk.org Wed Jan 7 12:41:56 2026 From: duke at openjdk.org (Eunbin Son) Date: Wed, 7 Jan 2026 12:41:56 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v3] In-Reply-To: References: Message-ID: > ### Summary > Fix incorrect regex usage in CoreUtils.getCoreFileLocation. > > ### Description > CoreUtils.getCoreFileLocation uses String.split("\s", 2). > The string literal "\s" represents a backspace character, not a whitespace regex. > As a result, the split operation does not separate fields on whitespace. > This change replaces the pattern with `"\\s+"` to correctly split on whitespace. > No other logic is modified. > > ### Bug ID : JDK-8374341 > https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 Eunbin Son has updated the pull request incrementally with one additional commit since the last revision: JDK-8374341: Remove unverified systemd-coredump handling code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28984/files - new: https://git.openjdk.org/jdk/pull/28984/files/a7596fa4..cc6e5f6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=01-02 Stats: 24 lines in 1 file changed: 0 ins; 24 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28984/head:pull/28984 PR: https://git.openjdk.org/jdk/pull/28984 From duke at openjdk.org Wed Jan 7 12:41:58 2026 From: duke at openjdk.org (Eunbin Son) Date: Wed, 7 Jan 2026 12:41:58 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 19:26:46 GMT, Kevin Walls wrote: >> Eunbin Son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374341: Update copyright year to 2025 for CoreUtils.java > > So that matching has never worked. 8-) > > But if we make this change, and it runs coredumpctl, does this now work as intended? > I see "No journal files were opened due to insufficient permissions." from coredumpctl (but I didn't test during a test that creates a core). > > Another problem may be the unpredictability of the timing when files are large: the 5 second sleep and the 10 iterations. Is that always enough? Maybe this is fine, but if it has never actually been used, the code should be verified well before it's enabled. > > On my systems when a core dump pattern has the "|", I am familiar with seeing the message "This system uses a crash report tool.." from later in the file. It tells you the system is configured inappropriately, so you fix the pattern manually, and all is good. > > Maybe we should delete lines 168 to 191 and simply have that message at line 192 printed, and a test skipped, if a core file pattern using "|" is in place. Thank you for the review, @kevinjwalls. You're right that this code has never worked, and I share your concerns about activating unverified code. I removed lines 168-191 and keep the skip message at line 192. This is safer and simpler. Thank you for the guidance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3718671633 From duke at openjdk.org Wed Jan 7 12:48:29 2026 From: duke at openjdk.org (Eunbin Son) Date: Wed, 7 Jan 2026 12:48:29 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: References: Message-ID: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> > ### Summary > Fix incorrect regex usage in CoreUtils.getCoreFileLocation. > > ### Description > CoreUtils.getCoreFileLocation uses String.split("\s", 2). > The string literal "\s" represents a backspace character, not a whitespace regex. > As a result, the split operation does not separate fields on whitespace. > This change replaces the pattern with `"\\s+"` to correctly split on whitespace. > No other logic is modified. > > ### Bug ID : JDK-8374341 > https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 Eunbin Son has 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: JDK-8374341: Remove unverified systemd-coredump handling code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28984/files - new: https://git.openjdk.org/jdk/pull/28984/files/cc6e5f6b..e0d36e8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28984&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28984/head:pull/28984 PR: https://git.openjdk.org/jdk/pull/28984 From lkorinth at openjdk.org Wed Jan 7 12:58:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:58:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02 Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From cjplummer at openjdk.org Wed Jan 7 17:08:24 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Jan 2026 17:08:24 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:31:51 GMT, Harald Eilertsen wrote: > It is in practice gone already, and has been for a long time. While the directories, files, classes and functions have "bsd" in them, they are in reality macOS sources. While some of it can be used unmodified on (some) other BSDs, most of it needs to be patched. > > So my idea was to move/rename this part that broke our port to better fit with reality, and then bring in the actual BSD code again in the BSD port. To me it feels cleaner, but I'll drop it if it's not wanted. Are you just referring to SA sources here, or also all the jdk library macosx directories and the hotspot os/bsd directory? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3719851293 From sspitsyn at openjdk.org Wed Jan 7 19:59:38 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Jan 2026 19:59:38 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:37:16 GMT, Eunbin Son wrote: > I removed lines 168-191 and keep the skip message at line 192. Then the bug and PR titles and descriptions have to be changed to match it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3720523422 From psandoz at openjdk.org Wed Jan 7 20:25:31 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 7 Jan 2026 20:25:31 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: Message-ID: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Including test changes from Bhavana Kilambi (ARM) > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Fix failing jtreg test in CI > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d Just some quick comments for now. I think this is better heading in the right direction. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436: > 434: } else { > 435: assert(Float16.valueOf(i).intValue() == i); > 436: } It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.) src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 3083: > 3081: * @return a {@code Float16Vector} with the same shape and information content > 3082: */ > 3083: public abstract Float16Vector reinterpretAsFloat16s(); At some point we should consider consolidating these methods into one which accepts the lane element type as an argument. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277: > 275: if (etype == Float16.class) { > 276: etype = short.class; > 277: } My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically. ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3636482293 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669808367 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669818576 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669827315 From duke at openjdk.org Thu Jan 8 00:23:55 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 8 Jan 2026 00:23:55 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit Thanks for the reviews and all of the suggestions ------------- PR Comment: https://git.openjdk.org/jdk/pull/28683#issuecomment-3721362471 From duke at openjdk.org Thu Jan 8 00:23:56 2026 From: duke at openjdk.org (duke) Date: Thu, 8 Jan 2026 00:23:56 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit @chadrako Your change (at version 739de617d72fa90fc868355719e790c6b3738934) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28683#issuecomment-3721363728 From sspitsyn at openjdk.org Thu Jan 8 00:45:29 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Jan 2026 00:45:29 GMT Subject: RFR: 6960970: Debugger very slow during stepping [v11] In-Reply-To: References: Message-ID: > This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame. > > This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked. > The other details will be provided in the first PR request comment. > > Testing: > - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage > - submitted mach5 tiers 1-6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge - Merge - merge: add fragments dropped by incorrect merge - merge: fix merge error - Merge - Merge - review: optimize hide_single_stepping and post_method_exit - review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS - review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx) - review: fix typo in a EATests.java comment - ... and 2 more: https://git.openjdk.org/jdk/compare/9a944e55...08edda18 ------------- Changes: https://git.openjdk.org/jdk/pull/28407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=10 Stats: 291 lines in 22 files changed: 194 ins; 61 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/28407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407 PR: https://git.openjdk.org/jdk/pull/28407 From sspitsyn at openjdk.org Thu Jan 8 00:51:04 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Jan 2026 00:51:04 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v5] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge - review: replace fix with just one assert - Merge - review: restored the assert and fixed the issue caused it to fire - 8373366: HandshakeState should disallow suspend ops for disabler threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d1f391b4..f2e6d731 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=03-04 Stats: 33054 lines in 2876 files changed: 11894 ins; 4275 del; 16885 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From lmesnik at openjdk.org Thu Jan 8 01:11:49 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Jan 2026 01:11:49 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: <-N01CwL7Mj3y4_P1Ytg31pJX08zT0P4PgkkGkNepW5g=.de7ea489-a0ec-4b3c-80c0-e73eefb83e0c@github.com> On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit @chadrako Thanks for all improvements! Friendly reminder - you need to wait for some reasonable until review from all people that has concerns. Just to ensure that you all are in agreement. Also, https://openjdk.org/guide/#hotspot-development says specific Hotspot rules. At least to reviews are needed for any non-trivial change. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28683#pullrequestreview-3637340896 From lmesnik at openjdk.org Thu Jan 8 01:14:52 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Jan 2026 01:14:52 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 03:45:35 GMT, Serguei Spitsyn wrote: >> I think `WHITE_BOX.fullGC()` blocks until the GC completes so I'm not sure a sleep is necessary. > > Thanks. I'm okay with as it is. Technically, the compiled unload events are deferred events and posted synchronically on another thread. So small delay helps to caught this event before starting next full GC cycle. However it is not very important here. So that's find to call GC until we reach for results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28683#discussion_r2670546331 From duke at openjdk.org Thu Jan 8 01:16:46 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 8 Jan 2026 01:16:46 GMT Subject: Integrated: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit In-Reply-To: References: Message-ID: <19hYxh6gAEz28Kv7lxT9Xli8pyQ7Z1z-BM0u_sryPCw=.069435be-3222-49be-949a-ae79bad51b3b@github.com> On Fri, 5 Dec 2025 22:23:46 GMT, Chad Rakoczy wrote: > [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) > > The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. This pull request has now been integrated. Changeset: 0a1fa219 Author: Chad Rakoczy Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/0a1fa219214b985e4c7d9e612bd5cda1b0f25577 Stats: 220 lines in 4 files changed: 88 ins; 99 del; 33 mod 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28683 From sspitsyn at openjdk.org Thu Jan 8 03:44:51 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Jan 2026 03:44:51 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing Message-ID: The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. The test update includes the following changes: - update method `ensureReadyAndWaiting()`: - add `sleep(50)` at start of method - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` - update method `checkStates()` to make it more stable and tracing output more clear Testing: - TBD: mach5 tiers 1-3 ------------- Commit messages: - fixed whitespace error - 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing Changes: https://git.openjdk.org/jdk/pull/29102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373643 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29102/head:pull/29102 PR: https://git.openjdk.org/jdk/pull/29102 From lmesnik at openjdk.org Thu Jan 8 04:45:54 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Jan 2026 04:45:54 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn wrote: > The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. > The test update includes the following changes: > - update method `ensureReadyAndWaiting()`: > - add `sleep(50)` at start of method > - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` > - update method `checkStates()` to make it more stable and tracing output more clear > > Testing: > - TBD: mach5 tiers 1-3 Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 48: > 46: > 47: public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) { > 48: sleep(50); // reliability: wait for a potential ReentrantLock class loading to complete It is not clear how ReentrantLock might be not loaded already. Can you please explain what do you mean? test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 134: > 132: expState, state, jvmtiExpState, singleState, multiState); > 133: > 134: if (state != expState) { Assuming that there is no way to find if thread is completely locked, might be it makes a sense to just make a few attempts of checking status? The test might sleep between attempts until got expected results. Even get them 3 times in a row. So test fails only if we can't get to expected results during some reasonable time. So test would be more stable. The only sleep between single check might be not enough in the case if VM/host is too busy. ------------- PR Review: https://git.openjdk.org/jdk/pull/29102#pullrequestreview-3637592479 PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2670801028 PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2670831765 From haraldei at openjdk.org Thu Jan 8 10:02:34 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Thu, 8 Jan 2026 10:02:34 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation > > It is in practice gone already, and has been for a long time. While the directories, files, classes and functions have "bsd" in them, they are in reality macOS sources. > > Are you just referring to SA sources here, or also all the jdk library macosx directories and the hotspot os/bsd directory? Both the SA and hotspot os/bsd directories. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3723110139 From kevinw at openjdk.org Thu Jan 8 17:56:34 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Jan 2026 17:56:34 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed Message-ID: vmTestbase/CollectionCounters test still unreliable. Avoid -Xcomp and use WhiteBox to cause GC. ------------- Commit messages: - Remove remaining 'randomness' - 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed Changes: https://git.openjdk.org/jdk/pull/29122/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374745 Stats: 57 lines in 5 files changed: 36 ins; 10 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29122/head:pull/29122 PR: https://git.openjdk.org/jdk/pull/29122 From kevinw at openjdk.org Thu Jan 8 17:56:34 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Jan 2026 17:56:34 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls wrote: > vmTestbase/CollectionCounters test still unreliable. > Avoid -Xcomp and use WhiteBox to cause GC. Recent changes in this test group are for a possible OOM failure and to make the iteration parameter behave as intended. Historically the test did not print to show its iterations, but the count was set to zero, and it was not clear how much testing actually happened (sometimes none depending on timing, as the stresser.continueExecution() check was before any testing). The iterations in this test do 3 activities that are meant to make the counters increase: eatMemory, System.gc, MemoryMXBean.gc. It performs 5 iterations now, which is not excessive but likely more than ever, and has now failed again. The latest failure is on linux aarch64 with "-XX:+UseZGC -Xcomp", and is a failure after the eatMemory test on the final iteration. (1) Why test with -Xcomp? That just adds timing complications. Various tests that are timing sensitive avoid -Xcomp, and this should also. (2) This can also migrate to using WhiteBox like suggested in JDK-8373945 for a larger set of tests. (3) The "randomness" keyword looks wrong. The eatMemory call used to fill with random content, but that didn't really matter as long as enough content was created. Maybe it was always meant to be "intermittent". But now it should be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29122#issuecomment-3724989272 From kfarrell at openjdk.org Thu Jan 8 19:19:37 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 19:19:37 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: > Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. > > This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'openjdk:master' into JDK_8359706 - comment - timed loop for aix and linux proc read - rm unused variables - updates - clean up - clean up - undo commit to linux.cpp - rm max count and malloc - bsd.cpp - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255 ------------- Changes: https://git.openjdk.org/jdk/pull/27971/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=05 Stats: 134 lines in 6 files changed: 134 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971 PR: https://git.openjdk.org/jdk/pull/27971 From cjplummer at openjdk.org Thu Jan 8 19:21:56 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Jan 2026 19:21:56 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:00:08 GMT, Harald Eilertsen wrote: > Both the SA and hotspot os/bsd directories. So what are your plans with the os/bsd directory? Rename it to something like os/darwin or os/macos, strip it of support that doesn't apply to macos, and then create a new os/bsd directory in your bsd project repo that only applies to a true bsd port. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3725307802 From haraldei at openjdk.org Thu Jan 8 19:41:21 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Thu, 8 Jan 2026 19:41:21 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:17:40 GMT, Chris Plummer wrote: > > Both the SA and hotspot os/bsd directories. > > So what are your plans with the os/bsd directory? Rename it to something like os/darwin or os/macos, strip it of support that doesn't apply to macos, and then create a new os/bsd directory in your bsd project repo that only applies to a true bsd port. If that's acceptable to the project, I think that it would be a good idea long term. In the short term, we're just trying to get the port working with as little disruption to upstream as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3725390201 From kfarrell at openjdk.org Thu Jan 8 19:42:50 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 19:42:50 GMT Subject: RFR: 8364182: Add jcmd VM.properties command Message-ID: The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. ------------- Commit messages: - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch Changes: https://git.openjdk.org/jdk/pull/29124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364182 Stats: 304 lines in 18 files changed: 186 ins; 77 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From kfarrell at openjdk.org Thu Jan 8 19:50:08 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 19:50:08 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into sec_props2 - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/cda609fc..232feeaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00-01 Stats: 211900 lines in 2740 files changed: 163444 ins; 31329 del; 17127 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From cjplummer at openjdk.org Thu Jan 8 20:01:25 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Jan 2026 20:01:25 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:37:17 GMT, Harald Eilertsen wrote: > If that's acceptable to the project, I think that it would be a good idea long term. In If those are your plans with os/bsd, I think before doing these changes to SA you should also hash out and get buy-in for the proposed changes to os/bsd. The SA changes are somewhat disruptive and need to be well thought out before we proceed. > In the short term, we're just trying to get the port working with as little disruption to upstream as possible. What would be the least disruptive would be to directly fix the existing BSD port without the proposed restructuring. Any idea why the recent changes broke the BSD port and how hard (and possibly disruptive) it would be to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3725518735 From duke at openjdk.org Thu Jan 8 20:07:45 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 8 Jan 2026 20:07:45 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch src/java.base/share/classes/java/security/Security.java line 802: > 800: } > 801: > 802: static Properties getAllSecurityPropertiesReadOnly() { is this method used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673707473 From kfarrell at openjdk.org Thu Jan 8 20:35:33 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 20:35:33 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: rm unused code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/232feeaa..81655c07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From kfarrell at openjdk.org Thu Jan 8 20:35:37 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 20:35:37 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch it seems the ability to hide JCMD commands via DCmdFactory, _hidden has been removed in JDK-8373441, I will search for an alternative method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725657806 From haraldei at openjdk.org Thu Jan 8 20:52:19 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Thu, 8 Jan 2026 20:52:19 GMT Subject: Withdrawn: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen wrote: > The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living. > > This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation. > > As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace. > > This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port. > > This work was sponsored by The FreeBSD Foundation This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29003 From haraldei at openjdk.org Thu Jan 8 20:52:17 2026 From: haraldei at openjdk.org (Harald Eilertsen) Date: Thu, 8 Jan 2026 20:52:17 GMT Subject: RFR: 8374372: Move OSX Serviceability Agent to macosx namespace In-Reply-To: References: Message-ID: <3AGexKsPQQPTzmPKrILuKAAgn5vEhJNkghfs8k7soXw=.ef813049-93ed-4ec9-b0ed-04fa0e6652b8@github.com> On Thu, 8 Jan 2026 19:58:00 GMT, Chris Plummer wrote: >>> > Both the SA and hotspot os/bsd directories. >>> >>> So what are your plans with the os/bsd directory? Rename it to something like os/darwin or os/macos, strip it of support that doesn't apply to macos, and then create a new os/bsd directory in your bsd project repo that only applies to a true bsd port. >> >> If that's acceptable to the project, I think that it would be a good idea long term. In the short term, we're just trying to get the port working with as little disruption to upstream as possible. > >> If that's acceptable to the project, I think that it would be a good idea long term. In > If those are your plans with os/bsd, I think before doing these changes to SA you should also hash out and get buy-in for the proposed changes to os/bsd. The SA changes are somewhat disruptive and need to be well thought out before we proceed. > >> In the short term, we're just trying to get the port working with as little disruption to upstream as possible. > What would be the least disruptive would be to directly fix the existing BSD port without the proposed restructuring. Any idea why the recent changes broke the BSD port and how hard (and possibly disruptive) it would be to fix. @plummercj Ok, will do that. Thanks for the feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29003#issuecomment-3725724121 From duke at openjdk.org Thu Jan 8 20:52:35 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 8 Jan 2026 20:52:35 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > rm unused code was there a reason why this was not simply added as an option to the existing Vm.system_properties jcmd? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725733678 From larry.cable at oracle.com Thu Jan 8 20:55:43 2026 From: larry.cable at oracle.com (Laurence Cable) Date: Thu, 8 Jan 2026 12:55:43 -0800 Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: <12eec818-70c0-4248-865f-c2a947ee2f8a@oracle.com> perhaps add this new functionality to the existing VM.system_properties jcmd as an option? On 1/8/26 12:35 PM, Kieran Farrell wrote: > On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell wrote: > >>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >>> >>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. >> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into sec_props2 >> - static helper method for both jcmd calls >> - missing ) >> - working with single arg >> - updates >> - update args >> - two args -not yet tested >> - initial patch > it seems the ability to hide JCMD commands via DCmdFactory, _hidden has been removed in JDK-8373441, I will search for an alternative method. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725657806 From kevinw at openjdk.org Thu Jan 8 21:04:41 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Jan 2026 21:04:41 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > rm unused code src/hotspot/share/services/attachListener.cpp line 308: > 306: } > 307: > 308: // Implementation of "properties -security" command. We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673891775 From kfarrell at openjdk.org Thu Jan 8 21:27:18 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 21:27:18 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v4] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - merge - rm unused code - Merge remote-tracking branch 'origin/master' into sec_props2 - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch ------------- Changes: https://git.openjdk.org/jdk/pull/29124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03 Stats: 29 lines in 6 files changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From duke at openjdk.org Thu Jan 8 22:11:18 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 8 Jan 2026 22:11:18 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> References: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> rm unused code > > src/hotspot/share/services/attachListener.cpp line 308: > >> 306: } >> 307: >> 308: // Implementation of "properties -security" command. > > We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... > > This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. > (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2674071763 From sspitsyn at openjdk.org Fri Jan 9 02:59:58 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 02:59:58 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls wrote: > vmTestbase/CollectionCounters test still unreliable. > Avoid -Xcomp and use WhiteBox to cause GC. Looks reasonable. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29122#pullrequestreview-3642131921 From lmesnik at openjdk.org Fri Jan 9 04:03:14 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 04:03:14 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls wrote: > vmTestbase/CollectionCounters test still unreliable. > Avoid -Xcomp and use WhiteBox to cause GC. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java line 83: > 81: updateCounters(); > 82: validate(false /* don't check gc count increases */); > 83: Algorithms.eatMemory(stresser); The corresponding import should be removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/29122#pullrequestreview-3642221537 PR Review Comment: https://git.openjdk.org/jdk/pull/29122#discussion_r2674713594 From sspitsyn at openjdk.org Fri Jan 9 04:24:19 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 04:24:19 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> References: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> Message-ID: <8R9pHuGcEu1_y8SLNnH2bYyFrFn4fLeYVTzHrBMibJw=.aef3de17-3774-4a11-a431-e786752f1ec0@github.com> On Thu, 8 Jan 2026 04:20:59 GMT, Leonid Mesnik wrote: >> The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. >> The test update includes the following changes: >> - update method `ensureReadyAndWaiting()`: >> - add `sleep(50)` at start of method >> - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` >> - update method `checkStates()` to make it more stable and tracing output more clear >> >> Testing: >> - TBD: mach5 tiers 1-3 > > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 48: > >> 46: >> 47: public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) { >> 48: sleep(50); // reliability: wait for a potential ReentrantLock class loading to complete > > It is not clear how ReentrantLock might be not loaded already. Can you please explain what do you mean? There can be more than one class. E.g., some can be involved on contention. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2674765502 From sspitsyn at openjdk.org Fri Jan 9 04:31:30 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 04:31:30 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> References: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> Message-ID: On Thu, 8 Jan 2026 04:41:59 GMT, Leonid Mesnik wrote: >> The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. >> The test update includes the following changes: >> - update method `ensureReadyAndWaiting()`: >> - add `sleep(50)` at start of method >> - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` >> - update method `checkStates()` to make it more stable and tracing output more clear >> >> Testing: >> - TBD: mach5 tiers 1-3 > > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 134: > >> 132: expState, state, jvmtiExpState, singleState, multiState); >> 133: >> 134: if (state != expState) { > > Assuming that there is no way to find if thread is completely locked, might be it makes a sense to just make a few attempts of checking status? > The test might sleep between attempts until got expected results. Even get them 3 times in a row. > So test fails only if we can't get to expected results during some reasonable time. So test would be more stable. > The only sleep between single check might be not enough in the case if VM/host is too busy. I did not want to go this way. My current goal is to make it clear the instability source is not on JVMTI side. Also, I think even 3 time checking approach will give some failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2674775027 From alanb at openjdk.org Fri Jan 9 08:04:24 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 08:04:24 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable wrote: >> src/hotspot/share/services/attachListener.cpp line 308: >> >>> 306: } >>> 307: >>> 308: // Implementation of "properties -security" command. >> >> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... >> >> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. >> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) > > I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary) Just some more history there. The reason the attachListener knows about the system properties command is because it dates back to JDK 6 when we introduced the attach mechanism and the Attach API. The Attach API defines VirtualMachine::getSystemProperties so both the tool and VM know about this "command". This all pre-dates jcmd and the diagnostic command framework that has been added since then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2675223455 From sjohanss at openjdk.org Fri Jan 9 08:47:01 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 Jan 2026 08:47:01 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 Thanks for looking into this Leo. Overall I think it looks good, just some small questions and suggestions. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637: > 1635: > 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const { > 1637: assert(_cm != nullptr, "thread must exist in order to check if mark is terminating"); I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427: > 2425: if (_cm->is_fully_initialized()) { > 2426: tc->do_thread(_cm->cm_thread()); > 2427: } Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()` src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549: > 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) { > 2548: assert(!_cm->in_progress(), "Can not start concurrent operation while in progress"); > 2549: assert(_cm->is_fully_initialized(), "sanity"); Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert. src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: > 44: return false; > 45: } > 46: Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? src/hotspot/share/gc/g1/g1Policy.cpp line 744: > 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { > 743: return false; > 744: } Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127: > 1125: > 1126: void G1YoungCollector::collect() { > 1127: _g1h->_cm->fully_initialize(); I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)` ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630 From alanb at openjdk.org Fri Jan 9 08:53:59 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 08:53:59 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v4] In-Reply-To: References: Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com> On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - merge > - rm unused code > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026. As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3727870283 From kfarrell at openjdk.org Fri Jan 9 09:54:08 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 09:54:08 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: References: Message-ID: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: hide command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/6675081d..ee7d4707 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03-04 Stats: 65 lines in 1 file changed: 25 ins; 10 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From kevinw at openjdk.org Fri Jan 9 10:13:03 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 10:13:03 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:43:09 GMT, Leonid Mesnik wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove import > > test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java line 83: > >> 81: updateCounters(); >> 82: validate(false /* don't check gc count increases */); >> 83: Algorithms.eatMemory(stresser); > > The corresponding import should be removed. Yes of course, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29122#discussion_r2675585432 From kevinw at openjdk.org Fri Jan 9 10:13:02 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 10:13:02 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed [v2] In-Reply-To: References: Message-ID: > vmTestbase/CollectionCounters test still unreliable. > Avoid -Xcomp and use WhiteBox to cause GC. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29122/files - new: https://git.openjdk.org/jdk/pull/29122/files/a43eacf2..a9956dbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29122&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29122&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29122/head:pull/29122 PR: https://git.openjdk.org/jdk/pull/29122 From kfarrell at openjdk.org Fri Jan 9 11:34:44 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 11:34:44 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> References: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > hide command > Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026. > Should this PR be put on hold until such a disccusion takes place or maybe that would be something a little further down the line? > As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command. My initial patch added a seperate command `VM.security_properties` but I merged the two following a suggestion reduce clutter in the the `jcmd help` output. Happy to revert to a seperate command if we proceed with this and there is a preference to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3728531839 From aartemov at openjdk.org Fri Jan 9 12:05:37 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 9 Jan 2026 12:05:37 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - 8366659: Fixed year in the copyright. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Removed ClearSuccOnSuspend - 8366659: Fixed liveness problem. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed build problem. - 8366659: Fixed build issue. - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed semi-broken tests - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=19 Stats: 1331 lines in 9 files changed: 882 ins; 417 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Fri Jan 9 12:05:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 9 Jan 2026 12:05:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v17] In-Reply-To: References: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com> Message-ID: On Mon, 24 Nov 2025 01:32:19 GMT, David Holmes wrote: >>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario? >> >> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :) >> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them. > > @sspitsyn so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes? > > We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing. The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress. > > Agreed the tests are completely artificial but there is no way to test this other than to do that. @dholmes-ora @sspitsyn Please take a look, I have re-worked a bit the logic with a hint from @pchilano. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3728629333 From duke at openjdk.org Fri Jan 9 12:07:10 2026 From: duke at openjdk.org (Eunbin Son) Date: Fri, 9 Jan 2026 12:07:10 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:56:18 GMT, Serguei Spitsyn wrote: >> Thank you for the review, @kevinjwalls. You're right that this code has never worked, >> and I share your concerns about activating unverified code. >> >> I removed lines 168-191 and keep the skip message at line 192. >> This is safer and simpler. Thank you for the guidance! > >> I removed lines 168-191 and keep the skip message at line 192. > > Then the bug and PR titles and descriptions have to be changed to match it. @sspitsyn Thank you. should I register a new bug report? Or, I think I can change this PR titles and descriptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3728633454 From stefank at openjdk.org Fri Jan 9 12:09:22 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 12:09:22 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: >> >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings >> >> Reviewed-by: aboldtch >> - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test >> >> Reviewed-by: serb, aivanov, dnguyen >> - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 > > I will redo the merge, I have done something strange. @lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315 From kevinw at openjdk.org Fri Jan 9 12:18:38 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 12:18:38 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> Message-ID: On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has 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: > > JDK-8374341: Remove unverified systemd-coredump handling code Yes we should update, no need for a new JBS issue. How about "Remove coredumpctl call in CoreUtils.getCoreFileLocation" I can update the JBS issue if you cannot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3728671700 From syan at openjdk.org Fri Jan 9 13:48:24 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 9 Jan 2026 13:48:24 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 Message-ID: Hi all, It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. So I think this test do not compatible with -Xcomp option. This PR add another "@requires'' to skip this test when jtreg receive -Xcomp option. ------------- Commit messages: - 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 Changes: https://git.openjdk.org/jdk/pull/29139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374879 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29139/head:pull/29139 PR: https://git.openjdk.org/jdk/pull/29139 From alanb at openjdk.org Fri Jan 9 14:33:22 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 14:33:22 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: References: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell wrote: > My initial patch added a seperate command `VM.security_properties` Maybe revert to that as it's a better starting point to discuss. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3729139127 From lmesnik at openjdk.org Fri Jan 9 16:24:54 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 16:24:54 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:13:02 GMT, Kevin Walls wrote: >> vmTestbase/CollectionCounters test still unreliable. >> Avoid -Xcomp and use WhiteBox to cause GC. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove import Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29122#pullrequestreview-3644658222 From kevinw at openjdk.org Fri Jan 9 16:48:37 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 16:48:37 GMT Subject: RFR: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed [v2] In-Reply-To: References: Message-ID: <3G7VsHQ9GTaR5sHQ3lFTMzZWwrLwMdIDdkYfjqlYU-w=.f605dd27-50af-4579-a485-0df6b1f0f60f@github.com> On Fri, 9 Jan 2026 10:13:02 GMT, Kevin Walls wrote: >> vmTestbase/CollectionCounters test still unreliable. >> Avoid -Xcomp and use WhiteBox to cause GC. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove import Thanks Leonid and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29122#issuecomment-3729757300 From kevinw at openjdk.org Fri Jan 9 16:53:01 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 16:53:01 GMT Subject: Integrated: 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls wrote: > vmTestbase/CollectionCounters test still unreliable. > Avoid -Xcomp and use WhiteBox to cause GC. This pull request has now been integrated. Changeset: f5fa9e40 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/f5fa9e40b09b7b6322edb5f057a6350d44980e14 Stats: 58 lines in 5 files changed: 36 ins; 11 del; 11 mod 8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/29122 From duke at openjdk.org Fri Jan 9 17:30:37 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 17:30:37 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 7 Jan 2026 10:07:02 GMT, Kevin Walls wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments > > src/hotspot/share/oops/instanceKlass.cpp line 2360: > >> 2358: >> 2359: InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; >> 2360: > > Looks good with the new local InstanceKlass ik. > Is it possible to not reassign into ik at lines 2386 and 2397, i.e. ik was the target class as an instanceKlass, but later represents pd or cs, so that can be hard to follow. I view "ik" like "i" in a for loop, I dont think that defining two additional InstanceKlass'es for "pd" or "cs" when their values are subsequently only used once is merited, but its subjective. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2676994050 From duke at openjdk.org Fri Jan 9 17:30:41 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 17:30:41 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 23:46:44 GMT, David Holmes wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments > > src/hotspot/share/oops/instanceKlass.cpp line 2386: > >> 2384: oop pd = java_lang_Class::protection_domain(k->java_mirror()); >> 2385: >> 2386: if (pd != nullptr && (ik = pd->klass()->is_instance_klass() ? InstanceKlass::cast(pd->klass()) : nullptr) != nullptr) { > > Is a non-instance-class possible here?? good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO, > src/hotspot/share/oops/instanceKlass.cpp line 2397: > >> 2395: oop cs = pd->obj_field(csfd.offset()); >> 2396: >> 2397: if (cs != nullptr && (ik = cs->klass()->is_instance_klass() ? InstanceKlass::cast(cs->klass()) : nullptr) != nullptr) { > > Is a non-instance-class possible here?? good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO > src/hotspot/share/oops/instanceKlass.cpp line 2406: > >> 2404: oop loc = cs->obj_field(locfd.offset()); >> 2405: >> 2406: if (loc != nullptr && loc->klass() == vmClasses::String_klass()) { > > Why are you checking the class type? I am simply reusing an existing pattern I found elsewhere in the corpus where code that accessed a field by name with the intent to process as a String tested the type, its my practice to code with safety, while its unlikely that the type of the field will change, I think its safer to test prior to invoking a type specific API. If you feel strongly about this, I will remove the klass comparision. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2676996740 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677014140 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677011507 From lmesnik at openjdk.org Fri Jan 9 17:40:38 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 17:40:38 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 The fix looks good. Thank you for this improvement. Hope it makes our testing more stable. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3644932150 From lmesnik at openjdk.org Fri Jan 9 17:46:02 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 17:46:02 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:26:30 GMT, Larry Cable wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2397: >> >>> 2395: oop cs = pd->obj_field(csfd.offset()); >>> 2396: >>> 2397: if (cs != nullptr && (ik = cs->klass()->is_instance_klass() ? InstanceKlass::cast(cs->klass()) : nullptr) != nullptr) { >> >> Is a non-instance-class possible here?? > > good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. The defensive code path might be fine for product to don't bother users with crashes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677066611 From kevinw at openjdk.org Fri Jan 9 17:58:35 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 17:58:35 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:22:04 GMT, Larry Cable wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2360: >> >>> 2358: >>> 2359: InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; >>> 2360: >> >> Looks good with the new local InstanceKlass ik. >> Is it possible to not reassign into ik at lines 2386 and 2397, i.e. ik was the target class as an instanceKlass, but later represents pd or cs, so that can be hard to follow. > > I view "ik" like "i" in a for loop, I dont think that defining two additional InstanceKlass'es for "pd" or "cs" when their values are subsequently only used once is merited, but its subjective. ok no problem ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677101240 From lmesnik at openjdk.org Fri Jan 9 18:01:47 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 18:01:47 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 13:41:22 GMT, SendaoYan wrote: > Hi all, > > It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. > So I think this test do not compatible with -Xcomp option. > > This PR add another "@requires'' to skip this test when jtreg receive -Xcomp option. I thought that vm.compMode != "Xcomp" should be enough. Should n't vm.compMode != "Xcomp" be true when it is null? ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29139#pullrequestreview-3645013770 From kfarrell at openjdk.org Fri Jan 9 18:38:53 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 18:38:53 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: References: Message-ID: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: sperate VM.sec_props command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/ee7d4707..db9e0e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=04-05 Stats: 63 lines in 3 files changed: 0 ins; 26 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From sspitsyn at openjdk.org Fri Jan 9 19:34:16 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 19:34:16 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v6] In-Reply-To: References: Message-ID: <6qb1Zla4PZRbLauSfNW0K6KlsoFNpDBGVO9KhGnT1vQ=.94a66d34-a2f0-49e3-bc29-4b259afac6bb@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: keep both: assert and disallow disabler suspend ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/f2e6d731..d2b9a341 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=04-05 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Fri Jan 9 19:43:28 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 19:43:28 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 00:02:26 GMT, Serguei Spitsyn wrote: > Agreed. We had a private slack discussion with Patricio and decided to construct a test case to catch this situation. I've decided to postpone JBS and PR description changes while I'm working on test coverage. I had to place a comment about it. Update: The issue was is reproducible with the new test (will add it to this PR shortly). Thanks to @pchilano for good ideas! So, current approach is to keep the original fix and also add an assert to the function `SuspendResumeManager::do_owner_suspend()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3730324923 From cjplummer at openjdk.org Fri Jan 9 19:46:00 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:46:00 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> Message-ID: <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com> On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has 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: > > JDK-8374341: Remove unverified systemd-coredump handling code BTW, we currently have an issue with our own internal testing when dealing with core files. Many hosts end up causing this "This system uses a crash report tool.." message, so we end up skipping the core file tests. The cause is the crash report tool being used to gzip the core file. I'm thinking of adding support in CoreUtils to check for core..gz, and unzip in that case. I think the code to do this would go exactly where this PR is removing the coredumpctl support. And regarding the removal of the coredumpctl support, this is the review of the change that introduced it: https://mail.openjdk.org/pipermail/serviceability-dev/2021-January/035127.html So this clearly worked at one point. However, in the original webrev (before feedback and changes), the code was in CiReplayBase.java and did not do the `endsWith("systemd-coredump")` check. So perhaps it worked then, but then when it was moved to CoreUtils.java during the review process, it was broken and not noticed. I'm not so sure removing the coredumpctl support at this point is the right thing to do. How was the \s error detected, and why do we think the right thing to do at this point is to remove this support rather than fix it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3730330529 From cjplummer at openjdk.org Fri Jan 9 19:57:11 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:11 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 Changes requested by cjplummer (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > 110: int iter = 0; > 111: while (num == 0) { > 112: // The unload is delayed because it happens asyns should be "async" ------------- PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3609731661 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2677442634 From cjplummer at openjdk.org Fri Jan 9 19:57:15 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:15 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update commnets for ClassUnloader test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > 40: * using WhiteBox.fullGC technique. > 41: * > 42: *

The method unloadClass() is provided which call should be "calls" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > 236: * > 237: * @throws Failure if exception other than OutOfMemoryError > 238: * is thrown while trigger full GC should be "triggering" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 248: > 246: customClassLoader = null; > 247: > 248: // force class unloading by trigger full GC should be "triggering" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644615480 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616395 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616746 From larry.cable at oracle.com Fri Jan 9 20:09:21 2026 From: larry.cable at oracle.com (Laurence Cable) Date: Fri, 9 Jan 2026 12:09:21 -0800 Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <60963a16-8960-493b-bbc6-37a384b2567e@oracle.com> ok will add such. On 1/9/26 9:46 AM, Leonid Mesnik wrote: > On Fri, 9 Jan 2026 17:26:30 GMT, Larry Cable wrote: > >>> src/hotspot/share/oops/instanceKlass.cpp line 2397: >>> >>>> 2395: oop cs = pd->obj_field(csfd.offset()); >>>> 2396: >>>> 2397: if (cs != nullptr && (ik = cs->klass()->is_instance_klass() ? InstanceKlass::cast(cs->klass()) : nullptr) != nullptr) { >>> Is a non-instance-class possible here?? >> good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO > I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. > The defensive code path might be fine for product to don't bother users with crashes. > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677066611 From cjplummer at openjdk.org Fri Jan 9 20:15:18 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 20:15:18 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack In-Reply-To: References: Message-ID: On Sat, 3 Jan 2026 10:22:25 GMT, Yasumasa Suenaga wrote: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java line 217: > 215: > 216: var sym = closestSymbolToPC(); > 217: if (sym != null && sym.getName().equals("")) { You are using "" in both C and java code. I think this should at least be called out in comments at each location so the readers knows they have to be kept in sync. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 49: > 47: > 48: public static Address getRegFromSignalTrampoline(Address sp, int index) { > 49: // ucontext_t locates at top of stack. Did you mean "is located"? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 52: > 50: // See definition of rt_sigframe in arch/x86/include/asm/sigframe.h > 51: // in Linux Kernel. > 52: Address addrUCMContext = sp.addOffsetTo(40); // offsetof(ucontext_t, uc_mcontext) = 40 Can we count on 40 always working across all kernels? test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 37: > 35: * @bug 8374482 > 36: * @requires (os.family == "linux") & (vm.hasSA) > 37: * @requires os.arch == "amd64" Do you think your fixes could also be applied to aarch64? I assume the same problem exists there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677486035 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677491443 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677493822 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677471639 From sspitsyn at openjdk.org Fri Jan 9 20:19:50 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 20:19:50 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v7] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: move is_vthread_transition_disabler out of DEBUG mode, update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d2b9a341..0405cb63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=05-06 Stats: 17 lines in 5 files changed: 2 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From cjplummer at openjdk.org Fri Jan 9 20:31:02 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 20:31:02 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 05:29:58 GMT, Yasumasa Suenaga wrote: >> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix split pattern for Windows > - Tweak toFrame() src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java line 653: > 651: private native long lookupByName0(String objName, String symName); > 652: private native ClosestSymbol lookupByAddress0(long address); > 653: private native long getFrameBase0(long sp, long pc); I don't see getFrameBase0() being implemented or called. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java line 62: > 60: // However it would not work for dynamic generated code like CodeBlob because > 61: // HotSpot would not register unwind info like RtlAddFunctionTable(). > 62: // Thus SA should check whether current PC is in CodeCache at first when nextPC is null. Suggestion: // The Windows GetStackTrace() Debug API can unwind the frame when given SP, FP, and PC. // However it will not work for dynamic generated code like CodeBlob because // HotSpot will not register unwind info like RtlAddFunctionTable(). // Thus SA should first check whether current PC is in the CodeCache when nextPC is null. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java line 113: > 111: public Frame toFrame() { > 112: // Find top of JavaVFrame relates to this CFrame because FP cannot be get > 113: // from GetStackTrace DbgHelp API on Windows. Suggestion: // Find the top of JavaVFrame related to this CFrame. The Windows GetStackTrace DbgHelp API // cannot get FP for java frames. src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp line 915: > 913: * Signature: (JJJ)[J > 914: */ > 915: JNIEXPORT jlongArray JNICALL Java_sun_jvm_hotspot_debugger_windbg_WindbgDebuggerLocal_getSenderRegs0 Some comments would be nice. I think what you are doing is getting the two stack frames starting at the one represented by the incoming registers, and then getting the registers from the 2nd frame. It would be nice to just make this clear in a comment,. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java line 53: > 51: .compile(LINE_MATCHER_STR); > 52: private static final String HEX_STR_PATTERN = "0x([a-fA-F0-9]+)"; > 53: private static final String FIB_SPLIT_PATTERN = "(NoFramePointer!)?" + NATIVE_FUNCTION_NAME It's unclear to me where NoFramePointer is coming from, and why this works on linux too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677532507 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677524380 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677517894 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677506840 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677500840 From duke at openjdk.org Fri Jan 9 21:11:18 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 21:11:18 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v3] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: added asserts ar per lmesnik comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/dd11893b..b4a97882 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=01-02 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From sspitsyn at openjdk.org Sat Jan 10 00:59:54 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 00:59:54 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing [v2] In-Reply-To: References: Message-ID: > The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. > The test update includes the following changes: > - update method `ensureReadyAndWaiting()`: > - add `sleep(50)` at start of method > - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` > - update method `checkStates()` to make it more stable and tracing output more clear > > Testing: > - TBD: mach5 tiers 1-3 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: tweak one of the comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29102/files - new: https://git.openjdk.org/jdk/pull/29102/files/3850f374..3ff0d66e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29102&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29102&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29102/head:pull/29102 PR: https://git.openjdk.org/jdk/pull/29102 From sspitsyn at openjdk.org Sat Jan 10 00:59:55 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 00:59:55 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing [v2] In-Reply-To: <8R9pHuGcEu1_y8SLNnH2bYyFrFn4fLeYVTzHrBMibJw=.aef3de17-3774-4a11-a431-e786752f1ec0@github.com> References: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com> <8R9pHuGcEu1_y8SLNnH2bYyFrFn4fLeYVTzHrBMibJw=.aef3de17-3774-4a11-a431-e786752f1ec0@github.com> Message-ID: <1rzFE66BYtuBjADODSAcddytxEk7jgZi4er_0lcEd-U=.395252a2-23cd-40f7-b883-d3f6af377cf1@github.com> On Fri, 9 Jan 2026 04:21:25 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 48: >> >>> 46: >>> 47: public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) { >>> 48: sleep(50); // reliability: wait for a potential ReentrantLock class loading to complete >> >> It is not clear how ReentrantLock might be not loaded already. Can you please explain what do you mean? > > There can be more than one class. E.g., some can be involved on contention. I've update the comment an removed the word `ReentrantLock` to avoid possible confusions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2678039810 From sspitsyn at openjdk.org Sat Jan 10 01:01:51 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 01:01:51 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: <_sBwN1Xl6x2wsJWWb3evXRSbRj1S4xEhpU1iVzr6zx4=.d5d7f38e-b12c-4f74-bac0-56a6e16127b3@github.com> On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn wrote: > The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. > The test update includes the following changes: > - update method `ensureReadyAndWaiting()`: > - add `sleep(50)` at start of method > - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` > - update method `checkStates()` to make it more stable and tracing output more clear > > Testing: > - TBD: mach5 tiers 1-3 This fix is a second correction of the test to make the output more clear. I wonder if it can be qualified as trivial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29102#issuecomment-3731187326 From ysuenaga at openjdk.org Sat Jan 10 01:42:15 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 01:42:15 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:11:15 GMT, Chris Plummer wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 52: > >> 50: // See definition of rt_sigframe in arch/x86/include/asm/sigframe.h >> 51: // in Linux Kernel. >> 52: Address addrUCMContext = sp.addOffsetTo(40); // offsetof(ucontext_t, uc_mcontext) = 40 > > Can we count on 40 always working across all kernels? Yes, this offset is valid since 14 years ago at least. I found the commit which affect to these struct: https://github.com/torvalds/linux/commit/af170c5061dd78512c469e6e2d211980cdb2c193 > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 37: > >> 35: * @bug 8374482 >> 36: * @requires (os.family == "linux") & (vm.hasSA) >> 37: * @requires os.arch == "amd64" > > Do you think your fixes could also be applied to aarch64? I assume the same problem exists there. There are same problem on aarch64 Linux, and actually I've made a change to fix it: https://github.com/YaSuenag/jdk/commit/b43f4f2172e9213d7e64fa9d9fd08f66eba5d335 However I decided not to include it in this PR because some frames (`VMError::report_and_die` at least) couldn't be unwinded. They seem to use FP as GPR (maybe cause by `-fomit-frame-pointer` when JVM is built). We need to handle DWARF like AMD64 Linux at first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678132974 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678125742 From lmesnik at openjdk.org Sat Jan 10 01:56:04 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 10 Jan 2026 01:56:04 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing [v2] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 00:59:54 GMT, Serguei Spitsyn wrote: >> The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. >> The test update includes the following changes: >> - update method `ensureReadyAndWaiting()`: >> - add `sleep(50)` at start of method >> - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` >> - update method `checkStates()` to make it more stable and tracing output more clear >> >> Testing: >> - TBD: mach5 tiers 1-3 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: tweak one of the comments Thanks for updating comment. The fix can be considered as trivial. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29102#pullrequestreview-3646243994 From ysuenaga at openjdk.org Sat Jan 10 02:01:37 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:01:37 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v3] In-Reply-To: References: Message-ID: > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java Co-authored-by: Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/d34dfa1c..4ba51c6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Sat Jan 10 02:01:39 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:01:39 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:24:15 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix split pattern for Windows >> - Tweak toFrame() > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java line 62: > >> 60: // However it would not work for dynamic generated code like CodeBlob because >> 61: // HotSpot would not register unwind info like RtlAddFunctionTable(). >> 62: // Thus SA should check whether current PC is in CodeCache at first when nextPC is null. > > Suggestion: > > // The Windows GetStackTrace() Debug API can unwind the frame when given SP, FP, and PC. > // However it will not work for dynamic generated code like CodeBlob because > // HotSpot will not register unwind info like RtlAddFunctionTable(). > // Thus SA should first check whether current PC is in the CodeCache when nextPC is null. Thank you! Applied. > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java line 53: > >> 51: .compile(LINE_MATCHER_STR); >> 52: private static final String HEX_STR_PATTERN = "0x([a-fA-F0-9]+)"; >> 53: private static final String FIB_SPLIT_PATTERN = "(NoFramePointer!)?" + NATIVE_FUNCTION_NAME > > It's unclear to me where NoFramePointer is coming from, and why this works on linux too. "NoFramePointer" is DLL name which is used in this test. Module (DLL) name added as prefix in mixed jstack on Windows. Thus I added it to regex pattern. It is regex pattern, I defined it as a group, and added `?` to it, so it works if module name does not appear like Linux. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2678169816 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2678168181 From ysuenaga at openjdk.org Sat Jan 10 02:00:37 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:00:37 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v2] In-Reply-To: References: Message-ID: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Fix - 8374482: SA does not handle signal handler frame in mixed jstack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/6abe46ad..8a0d9c48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=00-01 Stats: 33389 lines in 789 files changed: 15170 ins; 5750 del; 12469 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Sat Jan 10 02:00:39 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:00:39 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:07:41 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler >> - Fix >> - 8374482: SA does not handle signal handler frame in mixed jstack > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java line 217: > >> 215: >> 216: var sym = closestSymbolToPC(); >> 217: if (sym != null && sym.getName().equals("")) { > > You are using "" in both C and java code. I think this should at least be called out in comments at each location so the readers knows they have to be kept in sync. I added comments in both LinuxAMD64CFrame.java and symtab.c . > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 49: > >> 47: >> 48: public static Address getRegFromSignalTrampoline(Address sp, int index) { >> 49: // ucontext_t locates at top of stack. > > Did you mean "is located"? Thank you! Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678162496 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678162808 From ysuenaga at openjdk.org Sat Jan 10 02:18:06 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:18:06 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v4] In-Reply-To: References: Message-ID: > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Add comments - Remove unused declaration - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java Co-authored-by: Chris Plummer - Fix split pattern for Windows - Tweak toFrame() - 8374469: Mixed jstack does not work on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/4ba51c6e..ee6316bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=02-03 Stats: 33382 lines in 788 files changed: 15165 ins; 5751 del; 12466 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Sat Jan 10 02:18:09 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 02:18:09 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:27:28 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix split pattern for Windows >> - Tweak toFrame() > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java line 653: > >> 651: private native long lookupByName0(String objName, String symName); >> 652: private native ClosestSymbol lookupByAddress0(long address); >> 653: private native long getFrameBase0(long sp, long pc); > > I don't see getFrameBase0() being implemented or called. It is a garbage when I was struggling ? Removed it in new commit. > src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp line 915: > >> 913: * Signature: (JJJ)[J >> 914: */ >> 915: JNIEXPORT jlongArray JNICALL Java_sun_jvm_hotspot_debugger_windbg_WindbgDebuggerLocal_getSenderRegs0 > > Some comments would be nice. I think what you are doing is getting the two stack frames starting at the one represented by the incoming registers, and then getting the registers from the 2nd frame. It would be nice to just make this clear in a comment,. Added in new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2678195269 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2678192398 From syan at openjdk.org Sat Jan 10 03:02:24 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:02:24 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: > Hi all, > > It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. > So I think this test do not compatible with -Xcomp option. > > This PR add another "@requires'' to skip this test when jtreg receive -Xcomp option. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Use vm.compMode == "Xmixed" instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29139/files - new: https://git.openjdk.org/jdk/pull/29139/files/fde3e4bc..7d397b59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29139&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29139&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29139/head:pull/29139 PR: https://git.openjdk.org/jdk/pull/29139 From syan at openjdk.org Sat Jan 10 03:02:26 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:02:26 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: <89Q1HvAk4uiwjFQ0kv6QbXIBMVhF791BVL4dX0DKIk8=.ffbd43d0-875a-40f0-9396-e6c3e3e28287@github.com> On Fri, 9 Jan 2026 17:59:03 GMT, Leonid Mesnik wrote: > I thought that vm.compMode != "Xcomp" should be enough. Should n't vm.compMode != "Xcomp" be true when it is null? This is also incompatible to -Xint. So I use `vm.compMode == "Xmixed"` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29139#issuecomment-3731706595 From syan at openjdk.org Sat Jan 10 03:23:52 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:52 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Fix several typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/f72866e6..445515d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14-15 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Jan 10 03:23:54 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:54 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: <9ddgWMyuGEZC-ZMrnKQkD77T8ufCwsEsbUInbL8_eIM=.87e835a9-f05b-45d4-a437-ae5e00344fa5@github.com> On Fri, 9 Jan 2026 19:51:19 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Change the copyright year from 2025 to 2026 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > >> 110: int iter = 0; >> 111: while (num == 0) { >> 112: // The unload is delayed because it happens asyns > > should be "async" Sorry for the typo bug. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273418 From syan at openjdk.org Sat Jan 10 03:23:56 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:56 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> Message-ID: On Wed, 24 Dec 2025 02:05:21 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > >> 40: * using WhiteBox.fullGC technique. >> 41: * >> 42: *

The method unloadClass() is provided which call > > should be "calls" Thanks. Fixed. > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > >> 236: * >> 237: * @throws Failure if exception other than OutOfMemoryError >> 238: * is thrown while trigger full GC > > should be "triggering" Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678272674 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273095 From ysuenaga at openjdk.org Sat Jan 10 04:51:44 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 04:51:44 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v5] In-Reply-To: References: Message-ID: > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Add comments - Remove unused declaration - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java Co-authored-by: Chris Plummer - Fix split pattern for Windows - Tweak toFrame() - 8374469: Mixed jstack does not work on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/ee6316bd..f2530266 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=03-04 Stats: 163 lines in 5 files changed: 99 ins; 39 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Sat Jan 10 04:55:43 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 04:55:43 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v3] In-Reply-To: References: Message-ID: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Fix - 8374482: SA does not handle signal handler frame in mixed jstack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/8a0d9c48..10226995 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=01-02 Stats: 163 lines in 5 files changed: 99 ins; 39 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From sspitsyn at openjdk.org Sat Jan 10 08:15:59 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 08:15:59 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: References: Message-ID: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: add a test reproducing the bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/0405cb63..052a04cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=06-07 Stats: 251 lines in 2 files changed: 251 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Sat Jan 10 08:24:26 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 08:24:26 GMT Subject: RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing [v2] In-Reply-To: References: Message-ID: <2cxzCT5jafMBUQoLaIftouhYRezhyrldfVyBW0IImAE=.77904de3-7913-47b7-b750-11e4ed6305f9@github.com> On Sat, 10 Jan 2026 00:59:54 GMT, Serguei Spitsyn wrote: >> The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. >> The test update includes the following changes: >> - update method `ensureReadyAndWaiting()`: >> - add `sleep(50)` at start of method >> - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` >> - update method `checkStates()` to make it more stable and tracing output more clear >> >> Testing: >> - TBD: mach5 tiers 1-3 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: tweak one of the comments Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29102#issuecomment-3732146134 From sspitsyn at openjdk.org Sat Jan 10 11:14:02 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 11:14:02 GMT Subject: Integrated: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn wrote: > The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear. > The test update includes the following changes: > - update method `ensureReadyAndWaiting()`: > - add `sleep(50)` at start of method > - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)` > - update method `checkStates()` to make it more stable and tracing output more clear > > Testing: > - TBD: mach5 tiers 1-3 This pull request has now been integrated. Changeset: 12894a87 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/12894a870a3c8d1da13a885cc006458ae9475b6e Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/29102 From ysuenaga at openjdk.org Sun Jan 11 07:33:12 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 11 Jan 2026 07:33:12 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler - Fix - 8374482: SA does not handle signal handler frame in mixed jstack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/10226995..aa2ee284 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=02-03 Stats: 18 lines in 2 files changed: 7 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Sun Jan 11 07:41:33 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 11 Jan 2026 07:41:33 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack I added new test in this PR to check whether signal handler frame appears, but it will fail if debug symbol of libc is not available on test platform. This PR depends on the symbol named `__restore_rt`, but it does not seem to be exported by libc. On Fedora and Ubuntu, this PR would work fine after installing libc debug symbol - installing manually or downloading automatically by debuginfod. I'm concerned the test would fail on some test platforms (e.g. in Oracle). In GitHub Actions, most of SA tests seem to be skipped due to lack of permission for ptrace, thus this test and debuginfo requirement is not affected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3734180465 From ysuenaga at openjdk.org Sun Jan 11 07:45:11 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 11 Jan 2026 07:45:11 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v6] In-Reply-To: References: Message-ID: <8UViOVAZgXVOPXQL2GVLpry220R8-Q79krySUKpI6LM=.f91007d8-dbe8-415e-8784-91175148e82f@github.com> > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga 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 nine additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-win - Add comments - Remove unused declaration - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java Co-authored-by: Chris Plummer - Fix split pattern for Windows - Tweak toFrame() - 8374469: Mixed jstack does not work on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/f2530266..35d6fff2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=04-05 Stats: 18 lines in 2 files changed: 7 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Sun Jan 11 13:54:31 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 11 Jan 2026 13:54:31 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack This PR enabling signal handlers to be processed correctly, but it revealed a bug in DWARF parser. I fixed it in [here](https://github.com/YaSuenag/jdk/compare/jhsdb-jstack-sighandler...YaSuenag:jdk:mixed-jstack-fix-for-optimized-code), but I'm wondering whether this fix should also be included in this PR. What do you think? I think it should be fixed in another issue because this PR does not focus DWARF. I will file JBS and will create new PR after this of course. ClhsdbPstack.java for coredump and TestJhsdbJstackMixedCore.java introduced in this PR can pass, but they would not find Java caller frame of JNI. We can see NPE in both .jtr file because DWARF parser in SA could not find caller frame. Both tests uses libLingeredApp.c to crash due to access illegal address. It is very simple C code like following: // Borrowed from hotspot vmError.cpp. // Returns an address which is guaranteed to generate a SIGSEGV on read, // which is not NULL and contains bits in every word void* get_segfault_address() { return (void*) #ifdef _LP64 0xABC0000000000ABCULL; #else 0x00000ABC; #endif } JNIEXPORT jint JNICALL Java_jdk_test_lib_apps_LingeredApp_crash(JNIEnv *env, jclass clss) { return *(jint *)get_segfault_address(); } And it is compiled with `-O2` compiler option, then it has following assembly code - it does not make call frame! 00000000000003a0 : 3a0: a1 bc 0a 00 00 00 00 movabs 0xabc0000000000abc,%eax 3a7: c0 ab 3a9: c3 ret It does not have any DWARF instructions (NOP only in precise) of course: 00000054 0000000000000010 00000058 FDE cie=00000000 pc=00000000000003a0..00000000000003aa DW_CFA_nop DW_CFA_nop DW_CFA_nop I've created [simple reproducer](https://github.com/YaSuenag/garakuta/tree/master/NativeSEGV/frameless). It does not work on JDK 25.0.1 . ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3734578612 From chagedorn at openjdk.org Mon Jan 12 08:06:37 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 12 Jan 2026 08:06:37 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan wrote: >> Hi all, >> >> It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. >> So I think this test do not compatible with -Xcomp option. >> >> This PR add another "@requires'' to skip this test when jtreg receive -Xcomp or -Xint option. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use vm.compMode == "Xmixed" instead Looks good, thanks! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29139#pullrequestreview-3649537971 From serb at openjdk.org Mon Jan 12 08:26:49 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 12 Jan 2026 08:26:49 GMT Subject: RFR: 8374838: Apply java.io.Serial annotations in java.management.* Message-ID: Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the `java.management.*` modules. The goal is to enable stricter compile-time checking of serialization-related declarations. The change is not small. I could split it, but I decided to do it as a single change since covering the module in one shot is easier than managing a bunch of separate PRs. Example of a similar change https://github.com/openjdk/jdk/pull/24891. Note: this annotation can be applied to these methods and fields: * private void writeObject(java.io.ObjectOutputStream stream) throws IOException * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException * private void readObjectNoData() throws ObjectStreamException * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException * private static final ObjectStreamField[] serialPersistentFields * private static final long serialVersionUID Additional changes: - Copyright years were updated - Imports were not touched much (no sorting or cleanup); the new import was added in a reasonable place - In several places `static final long serialVersionUID =` was changed to `private static final long serialVersionUID =` ------------- Commit messages: - 8374838: Apply java.io.Serial annotations in javax.management.* Changes: https://git.openjdk.org/jdk/pull/29145/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374838 Stats: 550 lines in 138 files changed: 382 ins; 0 del; 168 mod Patch: https://git.openjdk.org/jdk/pull/29145.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29145/head:pull/29145 PR: https://git.openjdk.org/jdk/pull/29145 From kevinw at openjdk.org Mon Jan 12 12:12:11 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Jan 2026 12:12:11 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com> Message-ID: On Fri, 9 Jan 2026 19:42:11 GMT, Chris Plummer wrote: >> Eunbin Son 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: >> >> JDK-8374341: Remove unverified systemd-coredump handling code > > BTW, we currently have an issue with our own internal testing when dealing with core files. Many hosts end up causing this "This system uses a crash report tool.." message, so we end up skipping the core file tests. The cause is the crash report tool being used to gzip the core file. I'm thinking of adding support in CoreUtils to check for core..gz, and unzip in that case. I think the code to do this would go exactly where this PR is removing the coredumpctl support. > > And regarding the removal of the coredumpctl support, this is the review of the change that introduced it: > > https://mail.openjdk.org/pipermail/serviceability-dev/2021-January/035127.html > > So this clearly worked at one point. However, in the original webrev (before feedback and changes), the code was in CiReplayBase.java and did not do the `endsWith("systemd-coredump")` check. So perhaps it worked then, but then when it was moved to CoreUtils.java during the review process, it was broken and not noticed. > > I'm not so sure removing the coredumpctl support at this point is the right thing to do. How was the \s error detected, and why do we think the right thing to do at this point is to remove this support rather than fix it? Hi @plummercj I am presuming the the single backslash s typo was found by manual inspection or with a tool, @thswlsqls may want to confirm. It looks wrong. This match can never have worked? My system defaults to: # cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F ..so the match doesn't work, would never use the code that would be enabled here. BUT I think it would have worked by chance if the pattern was just "|/usr/lib/systemd/systemd-coredump" with no splitting possible or needed, and that may have been what was tested when integrated. I raised the point that correcting the typo needs testing to check it works as intended. i.e. we don't just appy the typo change. And an option is to remove the code if not tested or known good... But can coredumpctl really be useful here? If I change it to make the match work, and also make it print what the attempt to run "coredumpctl" sees, I get: Output and diagnostic info for process 1807382 was saved into 'pid-1807382-output.log' Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal', 'wheel' can see all messages. Pass -q to turn off this notice. No journal files were opened due to insufficient permissions. ..and then goes on to throw new SkippedException("This system uses a crash report tool"); (which it does if the match of systemd-coredump fails). So I see that recognising the pipe symbol is really benficial, as it prompts me to fix the system. But being so specific about matching systemd-coredump I'm not sure about the benefit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3738241630 From duke at openjdk.org Mon Jan 12 18:41:07 2026 From: duke at openjdk.org (Larry Cable) Date: Mon, 12 Jan 2026 18:41:07 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: added test for VM.classes -location as per lmesnik ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/b4a97882..c4d914ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From kevinw at openjdk.org Mon Jan 12 20:15:00 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Jan 2026 20:15:00 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: added test for VM.classes -location as per lmesnik src/hotspot/share/oops/instanceKlass.cpp line 2401: > 2399: oop cs = pd->obj_field(csfd.offset()); > 2400: > 2401: assert(cs !=nullptr && !cs->klass()->is_instance_klass(), "cs klass is not InstanceKlass"); Should we be asserting it is an instanceklass? (also int: cs != space nullptr while we are here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2683759759 From dholmes at openjdk.org Mon Jan 12 22:21:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Jan 2026 22:21:44 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit After this change the test is failing with: : name: compiledMethod, code: 0x0000ffff6c9ed5c0 : name: compiledMethod, code: 0x0000ffff6c9f4840 check_jvmti_error: JVMTI function returned error: get_method_name: error in JVMTI GetMethodName call: JVMTI_ERROR_INVALID_METHODID(23) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28683#issuecomment-3740777629 From duke at openjdk.org Mon Jan 12 22:31:27 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Mon, 12 Jan 2026 22:31:27 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:19:39 GMT, David Holmes wrote: >> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove JNIenv use and update shouldExit > > After this change the test is failing with: > > : name: compiledMethod, code: 0x0000ffff6c9ed5c0 > : name: compiledMethod, code: 0x0000ffff6c9f4840 > check_jvmti_error: JVMTI function returned error: get_method_name: error in JVMTI GetMethodName call: JVMTI_ERROR_INVALID_METHODID(23) @dholmes-ora Thanks for surfacing this issue I will look into it. Do you have any additional information on the failure such as failure frequency, environment, and reproducibility? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28683#issuecomment-3740809704 From dholmes at openjdk.org Tue Jan 13 02:04:59 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 02:04:59 GMT Subject: RFR: 8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit [v6] In-Reply-To: References: Message-ID: <2dJeB8VUOrH35LDp73WoiKbCi8Jt4kVt3bYtur_2CnI=.bcf814ea-3850-44aa-b9bf-f02af01e982f@github.com> On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy wrote: >> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150) >> >> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out. > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Remove JNIenv use and update shouldExit See [JDK-8375073](https://bugs.openjdk.org/browse/JDK-8375073) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28683#issuecomment-3741432980 From dholmes at openjdk.org Tue Jan 13 02:31:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 02:31:14 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan wrote: >> Hi all, >> >> It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. >> So I think this test do not compatible with -Xcomp option. >> >> This PR add another "@requires'' to skip this test when jtreg receive -Xcomp or -Xint option. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use vm.compMode == "Xmixed" instead It seems that prior to JDK-8369150 finding a null name was not a fatal error - though I'm unclear why Xcomp should trigger that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29139#issuecomment-3741512230 From dholmes at openjdk.org Tue Jan 13 05:36:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:40 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 23:41:52 GMT, David Holmes wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments > > src/hotspot/share/oops/instanceKlass.cpp line 2359: > >> 2357: // initialization state >> 2358: >> 2359: InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; > > Suggestion: > > InstanceKlass* ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr; Hotspot-style places the asterisk adjacent to the type not the variable name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684891342 From dholmes at openjdk.org Tue Jan 13 05:36:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:41 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:43:14 GMT, Leonid Mesnik wrote: >> good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO > > I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. > The defensive code path might be fine for product to don't bother users with crashes. My concern with "defensive coding" like this is that it implies we do not know the answer to the question and we should know it. In this case asserting we have an InstanceKlass seems preferabled to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684879556 From dholmes at openjdk.org Tue Jan 13 05:36:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:44 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:26:04 GMT, Larry Cable wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2406: >> >>> 2404: oop loc = cs->obj_field(locfd.offset()); >>> 2405: >>> 2406: if (loc != nullptr && loc->klass() == vmClasses::String_klass()) { >> >> Why are you checking the class type? > > I am simply reusing an existing pattern I found elsewhere in the corpus where code that accessed a field by name with the intent to process as a String tested the type, its my practice to code with safety, while its unlikely that the type of the field will change, I think its safer to test prior to invoking a type specific API. > > If you feel strongly about this, I will remove the klass comparision. :) Again an assertion would be better to catch this unlikely scenario. Though I suspect if the type of the field were to change then the use of the field would already trigger an assertion elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684886074 From dholmes at openjdk.org Tue Jan 13 05:42:19 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:19 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <-dk0O-wXKH9LTKENWaUTda4MJFuZo2bCeM7q4FpBSgQ=.ce715b56-569f-4693-8230-772753b408d1@github.com> On Tue, 13 Jan 2026 05:26:44 GMT, David Holmes wrote: >> I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. >> The defensive code path might be fine for product to don't bother users with crashes. > > My concern with "defensive coding" like this is that it implies we do not know the answer to the question and we should know it. In this case asserting we have an InstanceKlass seems preferabled to me. But again the assertion (if present) is in place of the runtime check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684904444 From dholmes at openjdk.org Tue Jan 13 05:42:18 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:18 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <6ErYQgKSAP_FuusjmifkjeFlhqLmfnTVXtRCbg18-P4=.31f7be43-053f-42f6-889e-7265d803a435@github.com> On Fri, 9 Jan 2026 17:22:58 GMT, Larry Cable wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2386: >> >>> 2384: oop pd = java_lang_Class::protection_domain(k->java_mirror()); >>> 2385: >>> 2386: if (pd != nullptr && (ik = pd->klass()->is_instance_klass() ? InstanceKlass::cast(pd->klass()) : nullptr) != nullptr) { >> >> Is a non-instance-class possible here?? > > good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO, Here the assertion should replace the runtime check. The (non-null) protection-domain object has to be an instance of `ProtectionDomain` which is an `InstanceKlass`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684901184 From dholmes at openjdk.org Tue Jan 13 05:42:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:16 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: added test for VM.classes -location as per lmesnik src/hotspot/share/oops/instanceKlass.cpp line 2359: > 2357: // initialization state > 2358: > 2359: assert(!k->is_instance_klass(), "not InstanceKlass!"); Why are you asserting this here? This code seems to expect any kind of `Klass`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684896375 From dholmes at openjdk.org Tue Jan 13 06:20:33 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:20:33 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Delay suspender whilst target is in-critical > - Revert "8373839: Disable JVM TI suspension during JNI critical regions" > > This reverts commit 7723275e4495cc1f514c531afe752210209617cc. Withdrawing this PR whilst a robust solution is sought. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3742167782 From dholmes at openjdk.org Tue Jan 13 06:20:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:20:34 GMT Subject: Withdrawn: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28884 From jbhateja at openjdk.org Tue Jan 13 09:48:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v10] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Including test changes from Bhavana Kilambi (ARM) - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Optimizing tail handling - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Cleanups - ... and 16 more: https://git.openjdk.org/jdk/compare/7e18de13...14861d5e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 515469 lines in 232 files changed: 284458 ins; 229216 del; 1795 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Tue Jan 13 09:48:50 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:50 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> References: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> Message-ID: <212JnoGQ5FDIEHJMmZ2zFLxmM4BCjqrnFyuZ6CqeZ-c=.cfa4503a-e6da-401b-95b4-f3c384d12e3f@github.com> On Wed, 7 Jan 2026 19:29:03 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Including test changes from Bhavana Kilambi (ARM) >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Optimizing tail handling >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Cleanups >> - Fix failing jtreg test in CI >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Cleanups >> - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436: > >> 434: } else { >> 435: assert(Float16.valueOf(i).intValue() == i); >> 436: } > > It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.) Done > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277: > >> 275: if (etype == Float16.class) { >> 276: etype = short.class; >> 277: } > > My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649510 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649160 From jbhateja at openjdk.org Tue Jan 13 09:58:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:58:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Adding testpoint for JDK-8373574 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/14861d5e..d1043144 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=09-10 Stats: 113 lines in 1 file changed: 113 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From fyang at openjdk.org Tue Jan 13 10:14:33 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:14:33 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: Message-ID: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> On Wed, 7 Jan 2026 09:03:03 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: >> >>> 1891: VectorMask m = three.compare(VectorOperators.LE, higher); >>> 1892: assert(m.allTrue()); >>> 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); >> >> I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? > > Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. Maybe we should fix them as well? test/jdk/jdk/incubator/vector/FloatVector256Tests.java test/jdk/jdk/incubator/vector/FloatVector128Tests.java test/jdk/jdk/incubator/vector/FloatVector64Tests.java test/jdk/jdk/incubator/vector/FloatVector512Tests.java test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java test/jdk/jdk/incubator/vector/DoubleVector128Tests.java test/jdk/jdk/incubator/vector/DoubleVector64Tests.java test/jdk/jdk/incubator/vector/DoubleVector256Tests.java test/jdk/jdk/incubator/vector/DoubleVector512Tests.java test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685722818 From fyang at openjdk.org Tue Jan 13 10:18:46 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:18:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> References: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> Message-ID: On Tue, 13 Jan 2026 10:10:40 GMT, Fei Yang wrote: >> Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. > > Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. > Maybe we should fix them as well? > > > test/jdk/jdk/incubator/vector/FloatVector256Tests.java > test/jdk/jdk/incubator/vector/FloatVector128Tests.java > test/jdk/jdk/incubator/vector/FloatVector64Tests.java > test/jdk/jdk/incubator/vector/FloatVector512Tests.java > test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java > > test/jdk/jdk/incubator/vector/DoubleVector128Tests.java > test/jdk/jdk/incubator/vector/DoubleVector64Tests.java > test/jdk/jdk/incubator/vector/DoubleVector256Tests.java > test/jdk/jdk/incubator/vector/DoubleVector512Tests.java > test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java Ah, that doesn't seem necessary after another look. Float16 is special here. So please ignore my comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685745615 From fyang at openjdk.org Tue Jan 13 10:27:39 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:27:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:58:29 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Adding testpoint for JDK-8373574 src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > 1651: * > 1652: * @param e the input scalar > 1653: * @return the result of multiplying this vector by the given scalar The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1694: > 1692: * > 1693: * @param e the input scalar > 1694: * @return the result of multiplying this vector by the given scalar Similar question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685766276 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685767490 From rkennke-openjdk at pm.me Tue Jan 13 11:19:10 2026 From: rkennke-openjdk at pm.me (Roman Kennke) Date: Tue, 13 Jan 2026 11:19:10 +0000 Subject: RFC: JVMTI async stack-walker POC Message-ID: Hi there, following up with discussions that took place between various folks from Oracle, Amazon, SAP and Datadog, I would like to propose two proof-of-concepts for a JVMTI async stack-walker API. Those are by no means complete implementations, but are meant to serve as a basis for further discussions. The goal of the proposed APIs is to replace the inherently unsafe, complex and unsupported AsyncGetCallTrace with a safe API that serves the same purpose as ASGCT. The requirements are: 1. the returned stack-traces are not safepoint-biased (there are already JVMTI APIs that return biased stack-traces). 2. the API is signal-safe (e.g. non-blocking, not calling into syscalls, doing allocations, etc) 3. Not exposing and don't make assumptions about JVM internals 4. Keep API surface as minimal as possible The first concept has been proposed by Oracle. It is a simple API to request a stack-trace through JVMTI. The stack-trace would be reported (asynchronously) through a JFR event. The API allows to pass a (jlong) 'user_data', which is then sent along with the JFR event. That way an agent has the ability to associate the stack-trace with whatever else it needs to do. https://github.com/openjdk/jdk/pull/29038 The PR also links to example code that shows how the API would be used in a simple HelloWorld profiling agent. The implementation uses the JFR CPU time sampler (https://openjdk.org/jeps/509) infrastructure for building and sending the stack-traces. It basically only extends the entry-point (from a signal handler) such that it can also accept a request from JVMTI, and the event-sending code, such that it can also send the new AsyncStackTrace event. Personally, I don't like that POC too much. I find it weird how it crosses subsystem boundaries (call JVMTI, get an event from JFR), and it is cumbersome to handle in a profiler agent (how to associate the JFR events with whatever the profiler agent wants to do). That is why I also made a second POC: The second POC proposes a JVMTI-only API. Like in the first POC, an agent can request a stack-trace through a signal-safe API. However, instead of getting a JFR, it would get the stack-trace via callback functions. This seems significantly cleaner to me, and seems to be in the spirit of various other JVMTI APIs (e.g. heap walking). Also, it has the advantage that it does not expose any JVM internals, makes no assumptions about datastructures, etc. https://github.com/openjdk/jdk/pull/29067 The POC implementation still uses the same JFR CPU time sampler, but that doesn't have to be so. In-fact, I think if we agree that this is the way to go, we would come up with a much cleaner design that implements a similar stack-walker infrastructure fully within JVMTI, or even let JFR and JVMTI share the same code for the async stack-walking, and clean up some weird an unnecessary dependencies on the way (e.g. with JFR thread sampling code). Please let me know what you think! Cheers, Roman From alan.bateman at oracle.com Tue Jan 13 17:11:27 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jan 2026 17:11:27 +0000 Subject: RFC: JVMTI async stack-walker POC In-Reply-To: References: Message-ID: On 13/01/2026 11:19, Roman Kennke wrote: > Hi there, > > following up with discussions that took place between various folks from Oracle, Amazon, SAP and Datadog, I would like to propose two proof-of-concepts for a JVMTI async stack-walker API. Those are by no means complete implementations, but are meant to serve as a basis for further discussions. > I see both PoCs propose standard APIs. JVMTI is Java SE and VM independent so would be problematic to have normative reference to "JFR" in the spec. Once you converge on a direction then it would be interesting to see if it could be exposed using the JVMTI extension mechanism as that would give you flexibility to make available JDK-specific features -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jan 13 20:44:37 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 13 Jan 2026 20:44:37 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: changes as per @dholmes and @kwalls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/c4d914ea..55d270dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=03-04 Stats: 13 lines in 1 file changed: 0 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From sspitsyn at openjdk.org Tue Jan 13 23:46:54 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Jan 2026 23:46:54 GMT Subject: [jdk26] RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing Message-ID: Please, review a jdk 26 backport. This pull request contains a clean backport of simple [12894a87](https://github.com/openjdk/jdk/commit/12894a870a3c8d1da13a885cc006458ae9475b6e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by @lmesnik . Thanks! ------------- Commit messages: - Backport 12894a870a3c8d1da13a885cc006458ae9475b6e Changes: https://git.openjdk.org/jdk/pull/29211/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29211&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373643 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29211.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29211/head:pull/29211 PR: https://git.openjdk.org/jdk/pull/29211 From dholmes at openjdk.org Wed Jan 14 00:09:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 00:09:44 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <360N0pFKAVnWO5eHeAi3XCvBEIesJCTAIWcooPYP_uw=.faa035f6-0380-4707-b21b-86ed97fe6d80@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: changes as per @dholmes and @kwalls src/hotspot/share/oops/instanceKlass.cpp line 2389: > 2387: > 2388: if (pd != nullptr) { > 2389: Suggestion: if (pd != nullptr) { assert(pd->klass()->is_instance_klass(), "pd klass is not InstanceKlass"); Nit: the asserts can be simplified by moving inside the null-checked regions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2688502321 From lmesnik at openjdk.org Wed Jan 14 00:19:15 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 00:19:15 GMT Subject: [jdk26] RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: <0pbt6G2mVWTJYMDYqoIEHjevbI4zKvA08P-Bm_820Rk=.c811cf19-be11-4627-a967-cad58610c9c1@github.com> On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple [12894a87](https://github.com/openjdk/jdk/commit/12894a870a3c8d1da13a885cc006458ae9475b6e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by @lmesnik . > > Thanks! Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29211#pullrequestreview-3658381713 From sspitsyn at openjdk.org Wed Jan 14 00:34:29 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 00:34:29 GMT Subject: [jdk26] RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple [12894a87](https://github.com/openjdk/jdk/commit/12894a870a3c8d1da13a885cc006458ae9475b6e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by @lmesnik . > > Thanks! Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29211#issuecomment-3747144154 From sspitsyn at openjdk.org Wed Jan 14 00:43:26 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 00:43:26 GMT Subject: [jdk26] Integrated: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple [12894a87](https://github.com/openjdk/jdk/commit/12894a870a3c8d1da13a885cc006458ae9475b6e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by @lmesnik . > > Thanks! This pull request has now been integrated. Changeset: da47f7a2 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/da47f7a27cc8ec68b40d025dc4cba108c6e18f97 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing Reviewed-by: lmesnik Backport-of: 12894a870a3c8d1da13a885cc006458ae9475b6e ------------- PR: https://git.openjdk.org/jdk/pull/29211 From dholmes at openjdk.org Wed Jan 14 01:30:51 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 01:30:51 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> References: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> Message-ID: On Sat, 10 Jan 2026 08:15:59 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: add a test reproducing the bug The functional fix seems fine. Could you provide a brief summary in the test about its structure and exactly what scenario it is creating to be tested - thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3658499404 From ysuenaga at openjdk.org Wed Jan 14 01:57:34 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 01:57:34 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME PING: Can I get Reviewers? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3747327414 From ysuenaga at openjdk.org Wed Jan 14 01:57:43 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 01:57:43 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year PING: Can I get second reviewer? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3747326910 From cjplummer at openjdk.org Wed Jan 14 05:21:49 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 05:21:49 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com> Message-ID: On Mon, 12 Jan 2026 12:06:04 GMT, Kevin Walls wrote: > It looks wrong. This match can never have worked? Yes, I agree with that, but as I pointed out, this check was added late in the review, so the code after the check was likely getting exercised and worked while the review was in process, but probably not tested well enough at the end of the review. > And an option is to remove the code if not tested or known good... I think the goal of the code is to give the core processing time to complete. I think for this use case, the core still ends up in the same location, but you just have to wait for it. Is that correct? If so, it would be useful for the work I'd like to see done to get the core file handling to work when the core file is zipped. Right now that results in SkippedException because the core file is not found. We could look for a .gz file, but I'm guessing we have to wait for it to appear, which is where this existing code comes in handy. If I'm not understanding this correctly, please let me know. > So I see that recognising the pipe symbol is really benficial, as it prompts me to fix the system. But being so specific about matching systemd-coredump I'm not sure about the benefit. I'm still fuzzy on what systemd-coredump is expected to do in the context of this CoreUtils code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3747812759 From cjplummer at openjdk.org Wed Jan 14 05:37:29 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 05:37:29 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 01:57:57 GMT, Yasumasa Suenaga wrote: >> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java line 53: >> >>> 51: .compile(LINE_MATCHER_STR); >>> 52: private static final String HEX_STR_PATTERN = "0x([a-fA-F0-9]+)"; >>> 53: private static final String FIB_SPLIT_PATTERN = "(NoFramePointer!)?" + NATIVE_FUNCTION_NAME >> >> It's unclear to me where NoFramePointer is coming from, and why this works on linux too. > > "NoFramePointer" is DLL name which is used in this test. Module (DLL) name added as prefix in mixed jstack on Windows. Thus I added it to regex pattern. It is regex pattern, I defined it as a group, and added `?` to it, so it works if module name does not appear like Linux. Ok. Please add a comment: // On windows the native symbol will be prefixed with "NoFramePointer!" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2689020541 From cjplummer at openjdk.org Wed Jan 14 05:38:09 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 05:38:09 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 10 Jan 2026 03:23:52 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Fix several typos Looks good now. Thanks! ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3658953058 From ysuenaga at openjdk.org Wed Jan 14 06:06:28 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 06:06:28 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v7] In-Reply-To: References: Message-ID: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update TestJhsdbJstackMixed.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/35d6fff2..8568a8fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=05-06 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From ysuenaga at openjdk.org Wed Jan 14 06:06:29 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 06:06:29 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 05:31:24 GMT, Chris Plummer wrote: >> "NoFramePointer" is DLL name which is used in this test. Module (DLL) name added as prefix in mixed jstack on Windows. Thus I added it to regex pattern. It is regex pattern, I defined it as a group, and added `?` to it, so it works if module name does not appear like Linux. > > Ok. Please add a comment: > > // On windows the native symbol will be prefixed with "NoFramePointer!" Thanks, added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2689073328 From lmesnik at openjdk.org Wed Jan 14 06:34:00 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 06:34:00 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <7kgAC4XAKsAf5OWtcoKHzLWZ9-X-7gkrSqZWlGfaswo=.60598d6d-f3a0-440d-a953-bf82de55a268@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748009565 From syan at openjdk.org Wed Jan 14 07:57:59 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 14 Jan 2026 07:57:59 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. > @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748276900 From jbhateja at openjdk.org Wed Jan 14 11:02:26 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 14 Jan 2026 11:02:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:22:25 GMT, Fei Yang wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding testpoint for JDK-8373574 > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > >> 1651: * >> 1652: * @param e the input scalar >> 1653: * @return the result of multiplying this vector by the given scalar > > The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? This is the problem in JDK-mainline code also, we should address it separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2689974123 From kevinw at openjdk.org Wed Jan 14 11:14:04 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 14 Jan 2026 11:14:04 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> Message-ID: <-Y6LJEwzHRV45UQlmPWUL_zYDy5wAYJQcE8mkEP74Zo=.79adde2b-55e1-4c36-9d3c-5dffb11984d6@github.com> On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has 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: > > JDK-8374341: Remove unverified systemd-coredump handling code Yes this has escalated a bit from the original typo submission. AIUI, systemd-coredump is invoked at the time of the crash due to the | coredump pattern, and will store the core in a directory that is not the pwd of the process (so we might not find it), so this code tries to recognise that and use coredumpctl to extract it. Yes this code could have worked as intended if the core dump pattern with no splitting ended in "systemd-coredump", but that does not look common (based on a smal sample of systems I use...). But coredumpctl also needs permission, which is not expected without being root or some other config steps, so the extraction from the /var/... directory generally fails. But that could have worked for some people when this was originally added, just seems unlikely it works generally. Internet searching summarises as: "coredumpctl needs root or privileged group access (like systemd-journal) because it reads system journal/coredump files usually owned by root in /var/lib/systemd/coredump, but you can grant specific users access by adding them to the right group or using sudo to access their own crashes..." Yes, I think the sleep(5000) and loop we have currently are about waiting for systemd-coredump to do its thing, and the core to be available in /var... before running coredumpctl to try and extract it. This is probably useful, but maybe it could have checked for more errors output from coredumptl and shown them. The current failure/fallback is fine for most users, it recognises that a core dump pattern invokes a tool, and warns. coredumpctl is currently invoked: String core = "core"; ProcessTools.executeProcess("coredumpctl", "dump", "-1", "-o", core, String.valueOf(pid)); dump Extract the last core dump matching specified characteristics. The core dump will be written on standard output, unless an output file is specified with --output=. -1 Show information of the most recent core dump only, instead of listing all known core dumps. Equivalent to --reverse -n 1. So it is also asking for the most recent coredump, which might be wrong if there are multiple crashes around the same time. MAYBE removing "-1" would be better, as this looks like it doesn't work if the last core dump is not from PID. But that's only worth looking at if there is a case that this coredumpctl code can be made generally useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3749034948 From fyang at openjdk.org Wed Jan 14 11:14:06 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Jan 2026 11:14:06 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: <53ngdNhoWJy4Cacq2Xs1bC0ulSPPVcUdz6WoSb3Pp6U=.699dfca7-3a7c-4f6b-addb-3c26b8f4c357@github.com> On Wed, 14 Jan 2026 10:58:44 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: >> >>> 1651: * >>> 1652: * @param e the input scalar >>> 1653: * @return the result of multiplying this vector by the given scalar >> >> The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? > > This is the problem in JDK-mainline code also, we should address it separately. Sure. I just realized that it is there for Float / Double varients as well in mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2690008963 From kevinw at openjdk.org Wed Jan 14 11:24:58 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 14 Jan 2026 11:24:58 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <1UIQCA4KZxbcVPvePdiXUYmBBdxOhmnK779XX85qIPo=.ea87b867-ee1d-4385-935b-a656591d9f5e@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: changes as per @dholmes and @kwalls Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3660231150 From alanb at openjdk.org Wed Jan 14 12:02:29 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 12:02:29 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> References: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> Message-ID: On Fri, 9 Jan 2026 18:38:53 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > sperate VM.sec_props command I think the latest proposal with `jcmd VM.security_properties` looks reasonable. My guess is that many developers don't know about security properties, or might think they are system properties that do something magic with security. So I think expand the current help/description from "Print security properties" to include "java.security.Security" in the text so there is somewhere to go and learn what this is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3749232175 From syan at openjdk.org Wed Jan 14 14:02:43 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 14 Jan 2026 14:02:43 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan wrote: >> Hi all, >> >> It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. >> So I think this test do not compatible with -Xcomp option. >> >> This PR add another "@requires'' to skip this test when jtreg receive -Xcomp or -Xint option. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use vm.compMode == "Xmixed" instead Looking the 2rd reviewer for touch hotspot files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29139#issuecomment-3749686758 From kfarrell at openjdk.org Wed Jan 14 15:31:21 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 14 Jan 2026 15:31:21 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update to print java.security.Security properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/db9e0e97..bb3b243c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From lmesnik at openjdk.org Wed Jan 14 15:56:08 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 15:56:08 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> Message-ID: On Wed, 14 Jan 2026 07:55:31 GMT, SendaoYan wrote: >>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. >> >> All the comments in touched tests has been checked. > >> @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. > > I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. @sendaoYan Thank you! Waiting for integration! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3750225072 From lmesnik at openjdk.org Wed Jan 14 16:13:32 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 16:13:32 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: References: Message-ID: <2qqTzoiovGkzLDS9fLbDABmH9-2I0TJlOKkJtpmB6GQ=.0fb59191-e674-44f0-bbc7-686cb0a0f61f@github.com> On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan wrote: >> Hi all, >> >> It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. >> So I think this test do not compatible with -Xcomp option. >> >> This PR add another "@requires'' to skip this test when jtreg receive -Xcomp or -Xint option. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use vm.compMode == "Xmixed" instead I think, the re-review is not needed if you have 2 reviews. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29139#pullrequestreview-3661553475 From cjplummer at openjdk.org Wed Jan 14 18:56:13 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 18:56:13 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> Message-ID: On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has 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: > > JDK-8374341: Remove unverified systemd-coredump handling code Marked as reviewed by cjplummer (Reviewer). There certainly can be multiple crashes around the same time given that we run the SA core file tests in parallel, so seems there are multiple issues with this support. I guess the best thing to do at this point is to remove it. I'll file a separate CR to deal with checking if the core file was zipped and try to unzip it. I'll references this CR as having removed some code that might be useful (waiting for the zipping to complete). ------------- PR Review: https://git.openjdk.org/jdk/pull/28984#pullrequestreview-3662277660 PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3751095041 From sspitsyn at openjdk.org Wed Jan 14 20:41:14 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 20:41:14 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: References: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> Message-ID: On Wed, 14 Jan 2026 01:27:45 GMT, David Holmes wrote: > Could you provide a brief summary in the test about its structure and exactly what scenario it is creating to be tested - thanks. Good suggestion. Will do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3751624921 From kevinw at openjdk.org Wed Jan 14 20:59:42 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 14 Jan 2026 20:59:42 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4] In-Reply-To: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> References: <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com> Message-ID: On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son wrote: >> ### Summary >> Fix incorrect regex usage in CoreUtils.getCoreFileLocation. >> >> ### Description >> CoreUtils.getCoreFileLocation uses String.split("\s", 2). >> The string literal "\s" represents a backspace character, not a whitespace regex. >> As a result, the split operation does not separate fields on whitespace. >> This change replaces the pattern with `"\\s+"` to correctly split on whitespace. >> No other logic is modified. >> >> ### Bug ID : JDK-8374341 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341 > > Eunbin Son has 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: > > JDK-8374341: Remove unverified systemd-coredump handling code Looks good. The titles of this PR and the JBS Issue should be updated as mentioned earlier. Agreed, multiple issues and the fallback message it prints is the most useful thing it does. Yes maybe we can come back here with improved handling... ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28984#pullrequestreview-3662739622 PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3751677986 From sspitsyn at openjdk.org Wed Jan 14 21:32:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 21:32:43 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v9] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: add general comment with testing scenario description for ThreadStateTest2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/052a04cd..d0f129f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=07-08 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From cjplummer at openjdk.org Wed Jan 14 22:50:08 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 22:50:08 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 06:02:16 GMT, Yasumasa Suenaga wrote: >> Ok. Please add a comment: >> >> // On windows the native symbol will be prefixed with "NoFramePointer!" > > Thanks, added. On windows-x64 I'm seeing about 25 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI frames. On other platforms I see just one Java_LingeredAppWithNativeMethod_callJNI frame, and a couple of fib() frames above it. Maybe this difference is just native compiler inlining and tail call elimination, but wanted to point it out just to make sure it is correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692335931 From cjplummer at openjdk.org Wed Jan 14 23:04:20 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 23:04:20 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack One concern I have with these changes is that they are somewhat complex (increasing technical debt), but don't do all that much (change signal handler frame from `????????` to ``). Do you find this functionality to be important when using SA to debug issues? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3752094866 From ysuenaga at openjdk.org Wed Jan 14 23:51:48 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 23:51:48 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack This PR aims to handle signal handler correctly - mixed jstack can be unwind the problematic call frame as a result. Then we can get correct SP/BP/PC, so we can unwind entire of call stacks including Java. We can (should) use native debugger to analyze native frames of course, but it is difficult to unwind Java frames - I think Java frames is important for Java developers because most of native calls come from Java. I completely agree this PR increases technical debt, so I give big +1 to use 3rd party unwinder like libunwind, but I think it is better to fix as possible if it is difficult to use it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3752226194 From ysuenaga at openjdk.org Thu Jan 15 00:51:59 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 15 Jan 2026 00:51:59 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:46:58 GMT, Chris Plummer wrote: >> Thanks, added. > > On windows-x64 I'm seeing about 25 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI frames. On other platforms I see just one Java_LingeredAppWithNativeMethod_callJNI frame, and a couple of fib() frames above it. Maybe this difference is just native compiler inlining and tail call elimination, but wanted to point it out just to make sure it is correct. On my Windows 11 25H2, mixed jstack works correctly like following: 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 0x00007ff8105c101d NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0x1d 0x000001c5903afbf8 * LingeredAppWithNativeMethod.callJNI(java.lang.Object, int) bci:0 (Interpreted frame) * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame) Do you mean multiple jstacks are shown in .jtr file with message such as "DEBUG: Iteration: 1 - Test didn't trigger interesting condition." ? If yes, I think it is expected. TestJhsdbJstackMixed.java seems to check at `isFibAndAlignedAddress` whether instruction address (PC) is aligned or not. I saw the condition is met in early on Linux x64, but it seems to take some calls on Windows x64. I'm not sure why we need to check this (I checked [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091) which introduced it, but I haven't yet understood the reason). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692562088 From sspitsyn at openjdk.org Thu Jan 15 01:23:29 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:23:29 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v10] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: problem list new test ThreadStateTest2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d0f129f7..3a82932c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=08-09 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Thu Jan 15 01:27:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:27:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v10] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 01:23:29 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: problem list new test ThreadStateTest2 I've problem-listed new test `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2` as it has been discovered new bug: https://bugs.openjdk.org/browse/JDK-8375362 . [PING!] This PR is ready for re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3752435240 PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3752436077 From cjplummer at openjdk.org Thu Jan 15 01:28:28 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 01:28:28 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack I thought this PR was just helping with the one signal handler frame. From the example stack trace you give in the description, it looks like other than the ???????? frame, the stack trace looks correct. I'm not seeing the situation where these changes are helping unwind java frames. Can you give an example? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3752436802 From cjplummer at openjdk.org Thu Jan 15 01:33:35 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 01:33:35 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:49:59 GMT, Yasumasa Suenaga wrote: >> On windows-x64 I'm seeing about 25 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI frames. On other platforms I see just one Java_LingeredAppWithNativeMethod_callJNI frame, and a couple of fib() frames above it. Maybe this difference is just native compiler inlining and tail call elimination, but wanted to point it out just to make sure it is correct. > > On my Windows 11 25H2, mixed jstack works correctly like following: > > > > 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 > 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 > 0x00007ff8105c101d NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0x1d > 0x000001c5903afbf8 * LingeredAppWithNativeMethod.callJNI(java.lang.Object, int) bci:0 (Interpreted frame) > * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) > * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame) > > > > > Do you mean multiple jstacks are shown in .jtr file with message such as "DEBUG: Iteration: 1 - Test didn't trigger interesting condition." ? If yes, I think it is expected. > > TestJhsdbJstackMixed.java seems to check at `isFibAndAlignedAddress` whether instruction address (PC) is aligned or not. I saw the condition is met in early on Linux x64, but it seems to take some calls on Windows x64. I'm not sure why we need to check this (I checked [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091) which introduced it, but I haven't yet understood the reason). "NoFramePointerJNIFib" #28 prio=5 tid=0x0000023fa4432290 nid=20612 runnable [0x000000d0370fe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007ffbe5fd10a8 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xa8 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffbe5fd101d NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0x1d 0x0000023f9300fcf8 * LingeredAppWithNativeMethod.callJNI(java.lang.Object, int) bci:0 (Interpreted frame) * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame) 0x0000023f93001952 0x0000023f93009300 * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame) 0x0000023f93001952 0x0000023f93009300 * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) * LingeredAppWithNativeMethod.lambda$main$0(LingeredAppWithNativeMethod) bci:1 line:71 (Interpreted frame) * LingeredAppWithNativeMethod$$Lambda+0x000000002b040b00.run() bci:4 (Interpreted frame) * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1529 (Interpreted frame) * java.lang.Thread.run() bci:19 line:1516 (Interpreted frame) 0x0000023f93001952 0x00007ffbc6d047c8 jvm!JavaCalls::call_helper + 0x3f8 0x00007ffbc72189ec jvm!os::os_exception_wrapper + 0x2c 0x00007ffbc6d05773 jvm!JavaCalls::call_virtual + 0x223 0x00007ffbc6d05b53 jvm!JavaCalls::call_virtual + 0x93 0x00007ffbc6e2f192 jvm!thread_entry + 0x82 0x00007ffbc6d3dce1 jvm!JavaThread::thread_main_inner + 0x261 0x00007ffbc747f15e jvm!Thread::call_run + 0x1be 0x00007ffbc7216ec4 jvm!thread_native_entry + 0xc4 0x00007ffbee504ea0 ucrtbase!wcsrchr + 0x1f0 0x00007ffbf03ddbe7 KERNEL32!BaseThreadInitThunk + 0x17 0x00007ffbf1165a6c ntdll!RtlUserThreadStart + 0x2c ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692626234 From sspitsyn at openjdk.org Thu Jan 15 01:34:28 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:34:28 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: References: Message-ID: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix trailing space in new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/3a82932c..00971481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From ysuenaga at openjdk.org Thu Jan 15 02:27:28 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 15 Jan 2026 02:27:28 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 01:29:50 GMT, Chris Plummer wrote: >> On my Windows 11 25H2, mixed jstack works correctly like following: >> >> >> >> 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 >> 0x00007ff8105c10c4 NoFramePointer!fib + 0x28 >> 0x00007ff8105c101d NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0x1d >> 0x000001c5903afbf8 * LingeredAppWithNativeMethod.callJNI(java.lang.Object, int) bci:0 (Interpreted frame) >> * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame) >> * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame) >> >> >> >> >> Do you mean multiple jstacks are shown in .jtr file with message such as "DEBUG: Iteration: 1 - Test didn't trigger interesting condition." ? If yes, I think it is expected. >> >> TestJhsdbJstackMixed.java seems to check at `isFibAndAlignedAddress` whether instruction address (PC) is aligned or not. I saw the condition is met in early on Linux x64, but it seems to take some calls on Windows x64. I'm not sure why we need to check this (I checked [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091) which introduced it, but I haven't yet understood the reason). > > "NoFramePointerJNIFib" #28 prio=5 tid=0x0000023fa4432290 nid=20612 runnable [0x000000d0370fe000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007ffbe5fd10a8 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xa8 > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffbe5fd10db NoFramePointe... I don't know why these call stacks were produced... It's strange. I tested this PR with cl.exe 19.50.35721 by VS 2026 18.1.1, I didn't see such call stacks. `callJNI()` makes recursive call, but it should include Java upcall (you can see it as LingeredAppWithNativeMethod.callback()`) Top of call stacks is `callJNI()`, thus I believe it has valid RSP/RBP/RIP (passed by `WindbgCDebugger::topFrameForThread`). `callJNI` is JNI function in NoFramePointer.dll generated by cl.exe (in usual (I believe) on OpenJDK build environment), thus I think `GetStackTrace` API works. Each `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` has instruction address, it means they were unwinded by the API, thus I think we need to investigate assembly code in NoFramePointer.dll to know what happens... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692734686 From syan at openjdk.org Thu Jan 15 02:47:18 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:47:18 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > Something strange is going on with this PR. I just got 3 separate emails for each of the following commits that were done in the past day: > > - [Fix the copy-n-paste error](https://github.com/openjdk/jdk/pull/28891/changes/349ae833fb600ab9136ab4f43749d1e5f2c84ca0) > - [Update commnets for ClassUnloader](https://github.com/openjdk/jdk/pull/28891/changes/6c144309a091038aaed1d698bd12323f3672c7b9) > - [Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java](https://github.com/openjdk/jdk/pull/28891/changes/e8d128e666ee0a8cbbf6d9dc273636b62bd3fb96) > > However, the PR claims that these commits were all done on Nov 22, not Dec. Thanks for the suggestions and reviews @plummercj @lmesnik. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3752622327 From syan at openjdk.org Thu Jan 15 02:48:50 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:48:50 GMT Subject: RFR: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 [v2] In-Reply-To: <2qqTzoiovGkzLDS9fLbDABmH9-2I0TJlOKkJtpmB6GQ=.0fb59191-e674-44f0-bbc7-686cb0a0f61f@github.com> References: <2qqTzoiovGkzLDS9fLbDABmH9-2I0TJlOKkJtpmB6GQ=.0fb59191-e674-44f0-bbc7-686cb0a0f61f@github.com> Message-ID: On Wed, 14 Jan 2026 16:09:57 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use vm.compMode == "Xmixed" instead > > I think, the re-review is not needed if you have 2 reviews. Thanks for the reviews and suggestions @lmesnik @chhagedorn ------------- PR Comment: https://git.openjdk.org/jdk/pull/29139#issuecomment-3752629940 From syan at openjdk.org Thu Jan 15 02:48:52 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:48:52 GMT Subject: Integrated: 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 In-Reply-To: References: Message-ID: <4WLwRmH9gGIJvLuvdWaD0GvnBc3M6BMroGIylzhPWUo=.7fd1507d-91ee-4db8-a39a-8c6ac7b3215f@github.com> On Fri, 9 Jan 2026 13:41:22 GMT, SendaoYan wrote: > Hi all, > > It seems that -Xcomp will compile all the java methods. And one of those method trigger NULL_CHECK assert inside jvmti->GetMethodName function. The method which trigger NULL_CHECK assert only observed when this test started by jtreg. > So I think this test do not compatible with -Xcomp option. > > This PR add another "@requires'' to skip this test when jtreg receive -Xcomp or -Xint option. This pull request has now been integrated. Changeset: 2b1e11c2 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/2b1e11c2541f799142bd71e9526cbd04743c6f4e Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 Reviewed-by: lmesnik, chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/29139 From syan at openjdk.org Thu Jan 15 02:50:03 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:50:03 GMT Subject: Integrated: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan wrote: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build This pull request has now been integrated. Changeset: ce5e0d8a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/ce5e0d8a48296b51c9c2eff4867e2a9a70194091 Stats: 421 lines in 62 files changed: 206 ins; 97 del; 118 mod 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28891 From ysuenaga at openjdk.org Thu Jan 15 02:58:20 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 15 Jan 2026 02:58:20 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack In worst case, we cannot unwind any call stacks under signal handler with exception due to referring invalid register value. https://github.com/openjdk/jdk/pull/29023#issuecomment-3734578612 is one of examples. "main" #3 prio=5 tid=0x00007f556002aa10 nid=1231 runnable [0x00007f5567d0a000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f5569509735 __GI_abort + 0x8b 0x00007f55680eadd5 os::abort(bool, void const*, void const*) [clone .cold] + 0x4 0x00007f5568efa717 VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) + 0x4f7 0x00007f5568efaf1b VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) + 0x8a 0x00007f5568efaf70 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x50 0x00007f5568d2ada3 JVM_handle_linux_signal + 0x2d2 0x00007f55695222c0 ???????? java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because "this.cfa" is null Signal handler should be handled as a special case because we cannot use normal unwind method on signal handler to get caller (problematic frame) registers (SP/BP/IP). Ideally the fix in [here](https://github.com/YaSuenag/jdk/compare/jhsdb-jstack-sighandler...YaSuenag:jdk:mixed-jstack-fix-for-optimized-code) should be included as I commented before, but I agree with you that it could increase technical debt... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3752660516 From cjplummer at openjdk.org Thu Jan 15 04:55:37 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 04:55:37 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 02:23:54 GMT, Yasumasa Suenaga wrote: >> "NoFramePointerJNIFib" #28 prio=5 tid=0x0000023fa4432290 nid=20612 runnable [0x000000d0370fe000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007ffbe5fd10a8 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xa8 >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb >> 0x00007ffbe5fd10d0 NoFramePointer!Java_LingeredAppWi... > > I don't know why these call stacks were produced... It's strange. > I tested this PR with cl.exe 19.50.35721 by VS 2026 18.1.1, I didn't see such call stacks. > > `callJNI()` makes recursive call, but it should include Java upcall (you can see it as LingeredAppWithNativeMethod.callback()`) > > Top of call stacks is `callJNI()`, thus I believe it has valid RSP/RBP/RIP (passed by `WindbgCDebugger::topFrameForThread`). `callJNI` is JNI function in NoFramePointer.dll generated by cl.exe (in usual (I believe) on OpenJDK build environment), thus I think `GetStackTrace` API works. > Each `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` has instruction address, it means they were unwinded by the API, thus I think we need to investigate assembly code in NoFramePointer.dll to know what happens... The binary I have was built with VS2022-17.13.2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692993002 From dholmes at openjdk.org Thu Jan 15 05:37:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 05:37:27 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: changes as per @dholmes and @kwalls Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3664017313 From dholmes at openjdk.org Thu Jan 15 05:54:49 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 05:54:49 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing space in new test test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java line 48: > 46: * - VT-2: a virtual thread: in a loop calls JVMTI InterruptThread(VT-0) and GetThreadState(VT-1) > 47: * - main: a platform thread: in a loop invokes native method testSuspendResume which suspends and resumes VT-2 > 48: * The JVMTI functionis above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). Suggestion: * The JVMTI functions above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2693081790 From dholmes at openjdk.org Thu Jan 15 06:04:09 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 06:04:09 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing space in new test I can't say that I understand what is happening in [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) but I do wonder if we need to get all the current VT issues resolved (in Loom repo?) before trying to update mainline. Maybe they are distinct issues but maybe there is some overlap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3753029067 From syan at openjdk.org Thu Jan 15 07:09:34 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 07:09:34 GMT Subject: RFR: 8375367: vmTestbase tests reported variable ininitialized by clang23 Message-ID: Hi all, The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[`].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. ------------- Commit messages: - 8375367: vmTestbase tests reported variable ininitialized by clang23 Changes: https://git.openjdk.org/jdk/pull/29247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375367 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29247/head:pull/29247 PR: https://git.openjdk.org/jdk/pull/29247 From ysuenaga at openjdk.org Thu Jan 15 08:17:00 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 15 Jan 2026 08:17:00 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 04:52:19 GMT, Chris Plummer wrote: >> I don't know why these call stacks were produced... It's strange. >> I tested this PR with cl.exe 19.50.35721 by VS 2026 18.1.1, I didn't see such call stacks. >> >> `callJNI()` makes recursive call, but it should include Java upcall (you can see it as LingeredAppWithNativeMethod.callback()`) >> >> Top of call stacks is `callJNI()`, thus I believe it has valid RSP/RBP/RIP (passed by `WindbgCDebugger::topFrameForThread`). `callJNI` is JNI function in NoFramePointer.dll generated by cl.exe (in usual (I believe) on OpenJDK build environment), thus I think `GetStackTrace` API works. >> Each `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` has instruction address, it means they were unwinded by the API, thus I think we need to investigate assembly code in NoFramePointer.dll to know what happens... > > The binary I have was built with VS2022-17.13.2. I saw same lines on [GHA results](https://github.com/YaSuenag/jdk/actions/runs/20984170537/artifacts/5123260970) - it used VS 2022 to build. Repeats of `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` is expected. It is inlined `fib()` as you said. I saw callJNI + 0xdb and 0xd0 are repeated as following: 0x00007ffa9b0e10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffa9b0e10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 0x00007ffa9b0e10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb 0x00007ffa9b0e10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 I got [GHA artifacts of debug build](https://github.com/YaSuenag/jdk/actions/runs/20984170537/artifacts/5122848054) and disassembled NoFramePointer.dll, then I saw following code around callJNI + 0xdb and 0xd0: 00000001800010A8: 48 89 5C 24 08 mov qword ptr [rsp+8],rbx 00000001800010AD: 57 push rdi 00000001800010AE: 48 83 EC 20 sub rsp,20h 00000001800010B2: 8B F9 mov edi,ecx 00000001800010B4: 85 C9 test ecx,ecx 00000001800010B6: 75 04 jne 00000001800010BC 00000001800010B8: 33 C0 xor eax,eax 00000001800010BA: EB 22 jmp 00000001800010DE 00000001800010BC: 83 FF 02 cmp edi,2 00000001800010BF: 7F 07 jg 00000001800010C8 00000001800010C1: B8 01 00 00 00 mov eax,1 00000001800010C6: EB 16 jmp 00000001800010DE 00000001800010C8: 83 C1 FE add ecx,0FFFFFFFEh 00000001800010CB: E8 D8 FF FF FF call 00000001800010A8 00000001800010D0: 8D 4F FF lea ecx,[rdi-1] 00000001800010D3: 48 8B D8 mov rbx,rax 00000001800010D6: E8 CD FF FF FF call 00000001800010A8 00000001800010DB: 48 03 C3 add rax,rbx It makes recursive call to 0x1800010A8 (callJNI + 0xa8) until the condition is met. According to NoFramePointer.dll.map in build artifact, callJNI + 0xa8 is `fib()` in libNoFramePointer.c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2693380875 From jbhateja at openjdk.org Thu Jan 15 08:56:21 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 15 Jan 2026 08:56:21 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Including test changes from Bhavana Kilambi (ARM) - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Optimizing tail handling - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519849 lines in 228 files changed: 285040 ins; 233032 del; 1777 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From sspitsyn at openjdk.org Thu Jan 15 09:58:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 09:58:41 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: fix typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/00971481..31c09156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Thu Jan 15 09:58:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 09:58:43 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 06:01:39 GMT, David Holmes wrote: > I can't say that I understand what is happening in [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) but I do wonder if we need to get all the current VT issues resolved (in Loom repo?) before trying to update mainline. Maybe they are distinct issues but maybe there is some overlap We've never had sufficient test coverage for `InterruptThread` in combination with `SuspendThread`. New test introduced in this PR found this new problem which I understand. It is better/simpler to address separately. It might require more investigation and testing even though I have a potential fix in mind. > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java line 48: > >> 46: * - VT-2: a virtual thread: in a loop calls JVMTI InterruptThread(VT-0) and GetThreadState(VT-1) >> 47: * - main: a platform thread: in a loop invokes native method testSuspendResume which suspends and resumes VT-2 >> 48: * The JVMTI functionis above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). > > Suggestion: > > * The JVMTI functions above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). Good catch, thanks! Fixed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3753828862 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2693702756 From rkennke-openjdk at pm.me Thu Jan 15 11:52:32 2026 From: rkennke-openjdk at pm.me (Roman Kennke) Date: Thu, 15 Jan 2026 11:52:32 +0000 Subject: RFC: JVMTI async stack-walker POC In-Reply-To: References: Message-ID: >> Hi there, >> >> following up with discussions that took place between various folks from Oracle, Amazon, SAP and Datadog, I would like to propose two proof-of-concepts for a JVMTI async stack-walker API. Those are by no means complete implementations, but are meant to serve as a basis for further discussions. > > I see both PoCs propose standard APIs. JVMTI is Java SE and VM independent so would be problematic to have normative reference to "JFR" in the spec. Once you converge on a direction then it would be interesting to see if it could be exposed using the JVMTI extension mechanism as that would give you flexibility to make available JDK-specific features > >> Hi Alan, thanks for offering your perspective. I have changed both POCs (and the corresponding example code) to implement as JVMTI extensions - I didn't even know that such a mechanism exists. They currently still use a capability to set up what they need (and that's in the public API unfortunately), I am wondering if there is something similar for JVMTI extensions? Worst case, I would perhaps add another extension function to initialize things. Also, is there any way for consumers of the API to get some documentation? The second POC uses callbacks, and I suppose it might be useful for a prospective user of the API to know the arguments etc of those. As it currently is, the callback functions are basically black boxes, reported by the extension mechanism as void* - the user of the API would have to know what functions exactly to pass as callbacks. (Worst case, I guess it could be described in a blog-post or so.) Cheers, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Thu Jan 15 12:21:26 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jan 2026 12:21:26 +0000 Subject: RFC: JVMTI async stack-walker POC In-Reply-To: References: Message-ID: On 15/01/2026 11:52, Roman Kennke wrote: > : > > thanks for offering your perspective. I have changed both POCs (and > the corresponding example code) to implement as JVMTI extensions - I > didn't even know that such a mechanism exists. > > They currently still use a capability to set up what they need (and > that's in the public API unfortunately), I am wondering if there is > something similar for JVMTI extensions? Worst case, I would perhaps > add another extension function to initialize things. > > Also, is there any way for consumers of the API to get some > documentation? The second POC uses callbacks, and I suppose it might > be useful for a prospective user of the API to know the arguments etc > of those. As it currently is, the callback functions are basically > black boxes, reported by the extension mechanism as void* - the user > of the API would have to know what functions exactly to pass as > callbacks. (Worst case, I guess it could be described in a blog-post > or so.) > I think it would be okay to have the equivalent of @implNote in the JVMTI spec. As part of the JEP 451 implementation we added an "Implementation Note" to the "Agent? Start-Up (Live phase)" section to document a -XX option. Maybe the "Stack frame" or some other section could have an implNote to document the functions? I don't think the extension mechanism anticipated new capabilities but it could be done, as you mention, with another extension function. (Serguei might have some ideas here but I suspect it could be problematic to use some of the bits for VM-specific capabilities). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From syan at openjdk.org Thu Jan 15 12:44:48 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 12:44:48 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan wrote: >> Hi all, >> >> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. >> >> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. >> >> Thanks! > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add an whitespace after if > > Co-authored-by: Andrey Turbanov Test-fix only, should we backport this fix to jdk26? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3754555700 From sspitsyn at openjdk.org Thu Jan 15 16:06:58 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 16:06:58 GMT Subject: RFR: 8375367: vmTestbase tests reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan wrote: > Hi all, > > The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[a].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. > > Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. This is a reasonable fix. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29247#pullrequestreview-3666391690 From mullan at openjdk.org Thu Jan 15 16:30:56 2026 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jan 2026 16:30:56 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update to print java.security.Security properties Please wait until someone from the Security Group reviews this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3755710214 From duke at openjdk.org Thu Jan 15 18:01:51 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 18:01:51 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: changes as per @dholmes and @kwalls @larry-cable Your change (at version 55d270dcc3e8f18806699449fc243942844ff8d4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3756167021 From duke at openjdk.org Thu Jan 15 18:56:14 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 18:56:14 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:31:06 GMT, Larry Cable wrote: >> src/hotspot/share/services/diagnosticCommand.cpp line 962: >> >>> 960: "S = is shared class", >>> 961: "BOOLEAN", false, "false"), >>> 962: _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") { >> >> Not a review yet. But this new functionality deserve a regression test. > > noted.... done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2695573695 From cjplummer at openjdk.org Thu Jan 15 19:11:13 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 19:11:13 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v7] In-Reply-To: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> References: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> Message-ID: On Wed, 14 Jan 2026 06:06:28 GMT, Yasumasa Suenaga wrote: >> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update TestJhsdbJstackMixed.java Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29019#pullrequestreview-3667145976 From cjplummer at openjdk.org Thu Jan 15 19:11:15 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 19:11:15 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:13:17 GMT, Yasumasa Suenaga wrote: >> The binary I have was built with VS2022-17.13.2. > > I saw same lines on [GHA results](https://github.com/YaSuenag/jdk/actions/runs/20984170537/artifacts/5123260970) - it used VS 2022 to build. Repeats of `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` is expected. It is inlined `fib()` as you said. > > I saw callJNI + 0xdb and 0xd0 are repeated as following: > > > 0x00007ffa9b0e10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffa9b0e10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > 0x00007ffa9b0e10db NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb > 0x00007ffa9b0e10d0 NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0 > > > I got [GHA artifacts of debug build](https://github.com/YaSuenag/jdk/actions/runs/20984170537/artifacts/5122848054) and disassembled NoFramePointer.dll, then I saw following code around callJNI + 0xdb and 0xd0: > > 00000001800010A8: 48 89 5C 24 08 mov qword ptr [rsp+8],rbx > 00000001800010AD: 57 push rdi > 00000001800010AE: 48 83 EC 20 sub rsp,20h > 00000001800010B2: 8B F9 mov edi,ecx > 00000001800010B4: 85 C9 test ecx,ecx > 00000001800010B6: 75 04 jne 00000001800010BC > 00000001800010B8: 33 C0 xor eax,eax > 00000001800010BA: EB 22 jmp 00000001800010DE > 00000001800010BC: 83 FF 02 cmp edi,2 > 00000001800010BF: 7F 07 jg 00000001800010C8 > 00000001800010C1: B8 01 00 00 00 mov eax,1 > 00000001800010C6: EB 16 jmp 00000001800010DE > 00000001800010C8: 83 C1 FE add ecx,0FFFFFFFEh > 00000001800010CB: E8 D8 FF FF FF call 00000001800010A8 > 00000001800010D0: 8D 4F FF lea ecx,[rdi-1] > 00000001800010D3: 48 8B D8 mov rbx,rax > 00000001800010D6: E8 CD FF FF FF call 00000001800010A8 > 00000001800010DB: 48 03 C3 add rax,rbx > > > It makes recursive call to 0x1800010A8 (callJNI + 0xa8) until the condition is met. According to NoFramePointer.dll.map in build artifact, callJNI + 0xa8 is `fib()` in libNoFramePointer.c. Ok. thanks for looking into this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2695610922 From cjplummer at openjdk.org Thu Jan 15 19:28:13 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 19:28:13 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack Marked as reviewed by cjplummer (Reviewer). > In worst case, we cannot unwind any call stacks under signal handler with exception due to referring invalid register value. [#29023 (comment)](https://github.com/openjdk/jdk/pull/29023#issuecomment-3734578612) is one of examples. Ok. I didn't realize there were also issues failing to walk the stack below the signal handler. ------------- PR Review: https://git.openjdk.org/jdk/pull/29023#pullrequestreview-3667207891 PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3756496150 From amenkov at openjdk.org Thu Jan 15 19:49:10 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 19:49:10 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <5THP-X2kZyt8lDj1tEPloBnzo3pG5hpHbzJewqcVNzQ=.3b8b92c8-dcd5-48a3-911c-ddf9d97f44f9@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: changes as per @dholmes and @kwalls build fails on windows. you need to fix it first ------------- Changes requested by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3667286292 From duke at openjdk.org Thu Jan 15 19:58:03 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 19:58:03 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: fixed Windows build issue and moved asserts as per @dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/55d270dc..22f27bee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=04-05 Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From amenkov at openjdk.org Thu Jan 15 20:10:27 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 20:10:27 GMT Subject: RFR: 8375367: vmTestbase tests reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan wrote: > Hi all, > > The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[a].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. > > Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. This `dummy` variable actually not needed, the tests should just pass `nullptr` as user_data. But suggested solution is ok ------------- Marked as reviewed by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29247#pullrequestreview-3667373694 From lmesnik at openjdk.org Thu Jan 15 20:31:59 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 20:31:59 GMT Subject: RFR: 8375367: vmTestbase tests reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan wrote: > Hi all, > > The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[a].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. > > Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29247#pullrequestreview-3667443964 From lmesnik at openjdk.org Thu Jan 15 20:34:40 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 20:34:40 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed Windows build issue and moved asserts as per @dholmes Thanks for adding test. It looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3667455032 From lmesnik at openjdk.org Thu Jan 15 23:02:23 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 23:02:23 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update to print java.security.Security properties This fix requires test for new added functionality. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3757287652 From duke at openjdk.org Thu Jan 15 23:10:30 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 23:10:30 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed Windows build issue and moved asserts as per @dholmes @larry-cable Your change (at version 22f27bee7c78997638ff53cd9d67e7f351576448) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3757310468 From dholmes at openjdk.org Thu Jan 15 23:23:43 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 23:23:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed Windows build issue and moved asserts as per @dholmes Changes requested by dholmes (Reviewer). test/hotspot/jtreg/runtime/CommandLine/PrintClasses.java line 65: > 63: pb.command(new PidJcmdExecutor().getCommandLine("VM.classes", "-location")); > 64: output = new OutputAnalyzer(pb.start()); > 65: output.stdoutContains(".*(file:/|jar:).*"); This won't report any failures - it is a boolean function. You need to use `stdoutShouldContain`. ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3668061308 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2696311622 From duke at openjdk.org Thu Jan 15 23:55:53 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 23:55:53 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: fixed test issue as identified by @dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/22f27bee..032897f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From pchilanomate at openjdk.org Fri Jan 16 00:46:52 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 00:46:52 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:58:41 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: fix typo in comment Thanks for adding the reproducer test Serguei. Looking at the newly filed [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) I see the problem is the same one described in this PR, it's just that the suspend checkpoint is not in the handshake processing logic but in `MountUnmountDisabler::start_transition`. So maybe it would make sense to fix them both here? BTW, looking at `JvmtiEnv::InterruptThread`, do we really need the disabler? `Thread.interrupt()` could be called directly from Java and we don't disable transitions on the target. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3757546393 From dholmes at openjdk.org Fri Jan 16 01:18:54 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 01:18:54 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed test issue as identified by @dholmes Seems okay now. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3668310458 From syan at openjdk.org Fri Jan 16 03:22:00 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 16 Jan 2026 03:22:00 GMT Subject: RFR: 8375367: vmTestbase tests reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:03:53 GMT, Serguei Spitsyn wrote: >> Hi all, >> >> The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[a].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. >> >> Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. > > This is a reasonable fix. Thanks for the reviews @sspitsyn @lmesnik @alexmenkov ------------- PR Comment: https://git.openjdk.org/jdk/pull/29247#issuecomment-3757930325 From syan at openjdk.org Fri Jan 16 03:22:01 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 16 Jan 2026 03:22:01 GMT Subject: Integrated: 8375367: vmTestbase tests reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan wrote: > Hi all, > > The local variable `dummy` is uninitialzed in function `static void JNICALL agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg)` at file test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002[a].cpp. This PR initial the local variable `dummy` explicitly to avoid compiler warning by clang23. > > Change has been verified locally by run the test entry test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/TestDescription.java. Test-fix only, no risk. This pull request has now been integrated. Changeset: e4474ad8 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/e4474ad8ae250771e031b8c18809d3e461970365 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8375367: vmTestbase tests reported variable uninitialized by clang23 Reviewed-by: sspitsyn, amenkov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/29247 From cjplummer at openjdk.org Fri Jan 16 03:45:39 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Jan 2026 03:45:39 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME I filed https://bugs.openjdk.org/browse/JDK-8306591 about 3 years ago, which noted that hotspot produces the following records, but SA does not: HPROF_GC_ROOT_STICKY_CLASS HPROF_GC_ROOT_JAVA_FRAME HPROF_GC_ROOT_NATIVE_STACK I suspected that this could lead to incomplete heap dumps. It seems with this PR you are fixing the lack of HPROF_GC_ROOT_JAVA_FRAME records in SA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3757979975 From cjplummer at openjdk.org Fri Jan 16 04:04:39 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Jan 2026 04:04:39 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: <4nx8jQYuLTkHA0-bPEK_NxnL1rK0C6-mDXBbH99Yabg=.3b70c0ef-0aa6-405f-8fe7-a9e15ea34046@github.com> On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java line 86: > 84: int length = maskLen - maxLocals; > 85: > 86: StackValueCollection result = new StackValueCollection(length); Can you explain why the expression stack is not always empty for native methods? I would think we would only care about parameters, and they would be returned by getLocals(), not getExpressions(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29058#discussion_r2696797239 From sspitsyn at openjdk.org Fri Jan 16 05:40:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 05:40:45 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: <3YW6u4XSgIA2yRcX-KNfYO750GaESL7hD1xboNadOyU=.3d1bc81b-5d43-4671-984d-8543a9c1c26c@github.com> On Fri, 16 Jan 2026 00:44:39 GMT, Patricio Chilano Mateo wrote: > Looking at the newly filed [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) I see the problem is the same one described in this PR, it's just that the suspend checkpoint is not in the handshake processing logic but in MountUnmountDisabler::start_transition. So maybe it would make sense to fix them both here? Good suggestion, thanks! I was thinking about the same. Okay will push an update for [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) here. > BTW, looking at JvmtiEnv::InterruptThread, do we really need the disabler? Thread.interrupt() could be called directly from Java and we don't disable transitions on the target. Thank you for the suggestion! I've tried it and got many failures of the tests depending on JVMTI `InterruptThread`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3758262690 From alanb at openjdk.org Fri Jan 16 07:17:43 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 07:17:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed test issue as identified by @dholmes Does the jcmd man page need to be updated? That is, I assume the intention is that it be a documented/supported option, which means it should have a CSR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3758508980 From sspitsyn at openjdk.org Fri Jan 16 08:00:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 08:00:01 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/31c09156..05b4c996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=11-12 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From ysuenaga at openjdk.org Fri Jan 16 08:24:50 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 16 Jan 2026 08:24:50 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: <4nx8jQYuLTkHA0-bPEK_NxnL1rK0C6-mDXBbH99Yabg=.3b70c0ef-0aa6-405f-8fe7-a9e15ea34046@github.com> References: <4nx8jQYuLTkHA0-bPEK_NxnL1rK0C6-mDXBbH99Yabg=.3b70c0ef-0aa6-405f-8fe7-a9e15ea34046@github.com> Message-ID: On Fri, 16 Jan 2026 04:02:23 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year in ConstantPool.java >> - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java line 86: > >> 84: int length = maskLen - maxLocals; >> 85: >> 86: StackValueCollection result = new StackValueCollection(length); > > Can you explain why the expression stack is not always empty for native methods? I would think we would only care about parameters, and they would be returned by getLocals(), not getExpressions(). In HotSpot, local stack and expression stack would be handled in same function. I just followed its manner in this patch. Stack values would be collected at `interpretedVFrame::stack_data` in both case, and it considers native methods of course. heapDumper.cpp if (vf->is_java_frame()) { javaVFrame* jvf = javaVFrame::cast(vf); if (!(jvf->method()->is_native())) { java_ref_dumper.set_frame_number(depth); java_ref_dumper.dump_java_stack_refs(jvf->locals()); java_ref_dumper.dump_java_stack_refs(jvf->expressions()); } else { vframe.cpp StackValueCollection* interpretedVFrame::locals() const { return stack_data(false); } StackValueCollection* interpretedVFrame::expressions() const { return stack_data(true); } /* * Worker routine for fetching references and/or values * for a particular bci in the interpretedVFrame. * * Returns data for either "locals" or "expressions", * using bci relative oop_map (oop_mask) information. * * @param expressions bool switch controlling what data to return (false == locals / true == expression) * */ StackValueCollection* interpretedVFrame::stack_data(bool expressions) const { InterpreterOopMap oop_mask; method()->mask_for(bci(), &oop_mask); const int mask_len = oop_mask.number_of_entries(); // If the method is native, method()->max_locals() is not telling the truth. // For our purposes, max locals instead equals the size of parameters. const int max_locals = method()->is_native() ? method()->size_of_parameters() : method()->max_locals(); But current SA and this PR are not aligned structure of HotSpot - SA does not have `stack_data` in `InterpretedVFrame`. Point of view of maintainance, it might be better to follow HotSpot. Should we refactor to follow HotSpot implementation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29058#discussion_r2697455521 From ysuenaga at openjdk.org Fri Jan 16 08:36:16 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 16 Jan 2026 08:36:16 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 03:42:18 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year in ConstantPool.java >> - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME > > I filed https://bugs.openjdk.org/browse/JDK-8306591 about 3 years ago, which noted that hotspot produces the following records, but SA does not: > > HPROF_GC_ROOT_STICKY_CLASS > HPROF_GC_ROOT_JAVA_FRAME > HPROF_GC_ROOT_NATIVE_STACK > > I suspected that this could lead to incomplete heap dumps. It seems with this PR you are fixing the lack of HPROF_GC_ROOT_JAVA_FRAME records in SA. @plummercj Thanks, I haven't been aware of JDK-8306591. I checked HotSpot again, heapDumper.cpp would dump `HPROF_GC_ROOT_STICKY_CLASS` and `HPROF_GC_ROOT_JAVA_FRAME`, but `HPROF_GC_ROOT_NATIVE_STACK` wouldn't be dumped I think. Should I close this and will start to work as JDK-8306591? or can I continue to work this? IMHO we can proceed this first because `HPROF_GC_ROOT_JAVA_FRAME` is very important to analyze memory leak, and it is very rare case that system classes (defined by null class loader) grabs large memory. I think it is ease to understand the commit if we make fix to align heapdump related code in SA to HotSpot in this PR, and add other unimplemented sub records like `HPROF_GC_ROOT_STICKY_CLASS` in another commits(s). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3758761803 From dholmes at openjdk.org Fri Jan 16 11:48:43 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 11:48:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed test issue as identified by @dholmes Alan - jcmds are considered diagnostics and don't require CSR requests. But yes this needs documenting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3759672504 From alanb at openjdk.org Fri Jan 16 12:12:52 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 12:12:52 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 11:45:25 GMT, David Holmes wrote: > Alan - jcmds are considered diagnostics and don't require CSR requests. But yes this needs documenting. They are diagnostic commands but we have been using CSRs to track additions as they are a documented interface, e.g. [JDK-8370204](https://bugs.openjdk.org/browse/JDK-8370204) and [JDK-833942](https://bugs.openjdk.org/browse/JDK-8339420). I may have it wrong as I thought we wanted a CSR for additions/changes to the CLI. (The output of a command is a different topic of course. Most commands yield unstructured/plain text that is not intended to be parsed, no CSR if the output changes. However there are a few commands that produce binary files or structured output that are intended to be parsed, and so are a supported interface for the CSR to track.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3759757569 From cjplummer at openjdk.org Fri Jan 16 17:52:44 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Jan 2026 17:52:44 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME I think it's fine to continue this PR with the bug you filed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3761145568 From cjplummer at openjdk.org Fri Jan 16 18:20:53 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Jan 2026 18:20:53 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: <4nx8jQYuLTkHA0-bPEK_NxnL1rK0C6-mDXBbH99Yabg=.3b70c0ef-0aa6-405f-8fe7-a9e15ea34046@github.com> Message-ID: <5WO4V4HjG8KU1NGnDqdk0vT32wIg2Qum_XqcBMn6xMY=.6c803b37-ae4a-4d89-8b4a-8766e6701bc3@github.com> On Fri, 16 Jan 2026 08:22:26 GMT, Yasumasa Suenaga wrote: > Point of view of maintainance, it might be better to follow HotSpot. Should we refactor to follow HotSpot implementation? It depends on how much complexity it adds. The PR is fairly easy to review now. It might be best to save refactoring for a follow-on PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29058#discussion_r2699523372 From duke at openjdk.org Fri Jan 16 18:52:11 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 16 Jan 2026 18:52:11 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: updated jcmd.md to document -location flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/032897f0..d29848e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=06-07 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From dholmes at openjdk.org Fri Jan 16 20:09:35 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:09:35 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 12:10:44 GMT, Alan Bateman wrote: > They are diagnostic commands but we have been using CSRs to track additions as they are a documented interface, e.g. [JDK-8370204](https://bugs.openjdk.org/browse/JDK-8370204) and [JDK-833942](https://bugs.openjdk.org/browse/JDK-8339420). I may have it wrong as I thought we wanted a CSR for additions/changes to the CLI. I guess it depends on who is involved with adding/modifying the command. There was no CSR request for [JDK-8344009](https://bugs.openjdk.org/browse/JDK-8344009), but there was for [JDK-8336401](https://bugs.openjdk.org/browse/JDK-8336401). I originally requested [JDK-8316922](https://bugs.openjdk.org/browse/JDK-8316922) but was then reminded that we don't need CSR requests in this area. So it is all a bit ad-hoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3761610159 From dholmes at openjdk.org Fri Jan 16 20:23:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:23:53 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 18:52:11 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: updated jcmd.md to document -location flag Changes requested by dholmes (Reviewer). src/jdk.jcmd/share/man/jcmd.md line 807: > 805: `R` = has been redefined, `S` = is shared class (BOOLEAN, false) > 806: > 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) Suggestion: - `-location`: (Optional) Print the location from which the class was loaded (if available). src/jdk.jcmd/share/man/jcmd.md line 808: > 806: > 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) > 808: If provided by its defining ClassLoader, this option will print a URL specifying the location of the I don't think this is an accurate description. The location comes from the `CodeSource` which comes from the `ProtectionDomain`, which is supplied to the `ClassLoader` when defining the Class. If we want to be specific here then I would suggest: If available from the Class (through its ProtectionDomain's CodeSource), this option will print ... ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3672561766 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699840495 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699855216 From dholmes at openjdk.org Fri Jan 16 20:58:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:58:22 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <3q7rDoxI_sOR7g90yvCKG8MFl8SyS1J3Nd8r9wfezgo=.2abaa58e-196d-44f2-b5a5-0a72153614de@github.com> On Fri, 16 Jan 2026 20:20:56 GMT, David Holmes wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated jcmd.md to document -location flag > > src/jdk.jcmd/share/man/jcmd.md line 808: > >> 806: >> 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) >> 808: If provided by its defining ClassLoader, this option will print a URL specifying the location of the > > I don't think this is an accurate description. The location comes from the `CodeSource` which comes from the `ProtectionDomain`, which is supplied to the `ClassLoader` when defining the Class. > > If we want to be specific here then I would suggest: > > If available from the Class (through its ProtectionDomain's CodeSource), this option will print ... And if we don't want to be specific then: If available, this option will print ... Though user's may wonder what makes it available, and how to make it available. I'm also wondering now whether this will show the "original" location, or the actual runtime location e.g CDS archive? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699938273 From dcubed at openjdk.org Fri Jan 16 22:09:52 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:09:52 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 Sorry for the long delay in getting back to this review. There a comment in ObjectMonitor::wait() that I think might be incorrect. See L1965 -> L1969 in src/hotspot/share/runtime/objectMonitor.cpp. I really like the refactoring that you've done with the test! Thumbs up on the code and most of the comments. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3672883715 From dcubed at openjdk.org Fri Jan 16 22:09:54 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:09:54 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v9] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 00:39:14 GMT, Serguei Spitsyn wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewer's comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1950: > >> 1948: // as having "-locked" the monitor, but the OS and java.lang.Thread >> 1949: // states will still report that the thread is blocked trying to >> 1950: // acquire it. > > Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). @dcubed-ojdk, could you comment on this, please? Sorry for the long delay in getting back to this review. Hmmmm... I'm wondering if that comment is correct: - We've creat `ExitOnSuspend eos` on L1961. - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`. - We reenter the monitor on L1964. - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below: - We call the `eos` object on the current thread BEFORE we `call process_if_requested` So it looks to me like we exit the monitor before we block for the safepoint so we should not be showing the monitor as "locked" by our "blocked" thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2700092565 From dcubed at openjdk.org Fri Jan 16 22:21:11 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:21:11 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v6] In-Reply-To: References: Message-ID: <5Y1HQt7NZK25GgtxctjN90D0HGEXi3LDyuoWcCmQz3E=.55e817a1-2427-464d-81f7-5c456abe422f@github.com> On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed lines in tests. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Added a comment to a boolean arg for enter() >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed new lines. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed incorrect assert, >> - 8366659: Fixed merge conflict >> - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6 > > So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java. > > I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended > thread made the successor over and over again so that none of the other contending threads > ever get the monitor even though it is unlocked. > > I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread > manages to re-enter the monitor and then gets suspended while on its way back to Java. > > @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two > new test cases to the two deadlocks. Thanks! > is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario? @dcubed-ojdk, what do you think? Sorry for the long delay in getting back to this thread. Yes, the original SuspendWithObjectMonitorWait demonstrated a real-world scenario and it reproduced a bug in the JVM where a suspended thread was allowed to enter a monitor. That violated the SuspendThread contract that after return from the call, the target thread will execute no more bytecode or byte-code equivalents. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762019821 From dcubed at openjdk.org Fri Jan 16 22:25:47 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:25:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 See the original issue from JDK1.3.1 here: [JDK-4413752](https://bugs.openjdk.org/browse/JDK-4413752) Linux: suspended thread blocks raw ObjectMonitor entry ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762029149 From larry.cable at oracle.com Fri Jan 16 22:28:21 2026 From: larry.cable at oracle.com (Laurence Cable) Date: Fri, 16 Jan 2026 14:28:21 -0800 Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: <3q7rDoxI_sOR7g90yvCKG8MFl8SyS1J3Nd8r9wfezgo=.2abaa58e-196d-44f2-b5a5-0a72153614de@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> <3q7rDoxI_sOR7g90yvCKG8MFl8SyS1J3Nd8r9wfezgo=.2abaa58e-196d-44f2-b5a5-0a72153614de@github.com> Message-ID: <3d5ade82-6f6a-4051-b034-997c0557ab8a@oracle.com> On 1/16/26 12:58 PM, David Holmes wrote: > On Fri, 16 Jan 2026 20:20:56 GMT, David Holmes wrote: > >>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >>> >>> JDK-8327246: updated jcmd.md to document -location flag >> src/jdk.jcmd/share/man/jcmd.md line 808: >> >>> 806: >>> 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) >>> 808: If provided by its defining ClassLoader, this option will print a URL specifying the location of the >> I don't think this is an accurate description. The location comes from the `CodeSource` which comes from the `ProtectionDomain`, which is supplied to the `ClassLoader` when defining the Class. >> >> If we want to be specific here then I would suggest: >> >> If available from the Class (through its ProtectionDomain's CodeSource), this option will print ... > And if we don't want to be specific then: > > If available, this option will print ... > > Though user's may wonder what makes it available, and how to make it available. > > I'm also wondering now whether this will show the "original" location, or the actual runtime location e.g CDS archive? it depends on what CDS does with class static fields upon reification, I expect that it would report the original location... @iklam can you comment pls, BTW should the VM.classes jcmd also be modified to report CDS membership/containment of a loaded class? - Larry > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699938273 From dcubed at openjdk.org Fri Jan 16 22:28:53 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:28:53 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v17] In-Reply-To: References: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com> Message-ID: <_IIvFo-i2TXxNeeJ0gzRl_xEleoHrzzApvsmEBH8P8s=.aaafc329-87d3-4cdc-93c9-40f4919a69f6@github.com> On Mon, 24 Nov 2025 10:22:12 GMT, Serguei Spitsyn wrote: > The thread was picked as a successor and then suspended. It feels like it has to be qualified same as a thread owns the monitor and suspended. The successor protocol is an internal implementation detail of ObjectMonitor. It is NOT exposed to person debugging their Java program. Just because a suspend thread is marked as the successor, that does NOT mean it should prevent other non-suspended threads from entering the monitor. In other words, being the successor IS NOT the same as owning the monitor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762044144 From dcubed at openjdk.org Fri Jan 16 22:34:59 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:34:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 I have to disagree that the notion that test case #2 and test case #3 are "artificial". These tests were written to line up the executing conditions to reproduce the two failure modes posited by the bug. Both of the new test cases, when executed on a VM without the product code changes cause a definite liveness condition. Maybe we should have said "hang" instead of "deadlock". Maybe even "livelock" is better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762066851 From sspitsyn at openjdk.org Fri Jan 16 22:41:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 22:41:01 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: <6HSpZhqgIttyqFw-sz7eielDrrzdBHDGWj7Pm-TE_ko=.9dec4a59-08b6-4e46-86a7-2681c6719004@github.com> On Fri, 16 Jan 2026 08:00:01 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread I've added the following fix for [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) as we agreed with Patricio: @@ -129,7 +129,8 @@ bool MountUnmountDisabler::is_start_transition_disabled(JavaThread* thread, oop int base_disable_count = notify_jvmti_events() ? 1 : 0; return java_lang_Thread::vthread_transition_disable_count(vthread) > 0 || global_vthread_transition_disable_count() > base_disable_count JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended())); JVMTI_ONLY(|| (!thread->is_vthread_transition_disabler() && (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()))); } void MountUnmountDisabler::start_transition(JavaThread* current, oop vthread, bool is_mount, bool is_thread_end) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3762080269 From amenkov at openjdk.org Sat Jan 17 00:59:27 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 17 Jan 2026 00:59:27 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3673321098 From syan at openjdk.org Sat Jan 17 04:10:54 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 17 Jan 2026 04:10:54 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 Message-ID: Hi all, This PR make 2 changes which make test more rubustness: 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. Additional testing: - [ ] All tests touched test by JDK-8373945 ------------- Commit messages: - 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after JDK-8373945 Changes: https://git.openjdk.org/jdk/pull/29285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375485 Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From ysuenaga at openjdk.org Sat Jan 17 06:27:31 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 17 Jan 2026 06:27:31 GMT Subject: Integrated: 8373867: Improve robustness of Attach API for finding tmp directory In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:39:44 GMT, Yasumasa Suenaga wrote: > We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. > > > $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep > [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 > 2025-12-17 06:34:37 > Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): > > Threads class SMR info: > _java_thread_list=0x000078a8bc13f200, length=10, elements={ > 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, > 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, > : > > > Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). > > In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: > > > $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug > / # /usr/lib/jvm/jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded > at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > > / # ls -l /proc/1/cwd > ls: /proc/1/cwd: cannot read link: Permission denied > lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd > > > > After this change, we can see following exception on the console of jcmd when we encounter this situation: > > # jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm... This pull request has now been integrated. Changeset: 436c62af Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/436c62afd285a3ce2be9aef59876df4b9f0955ff Stats: 160 lines in 3 files changed: 144 ins; 6 del; 10 mod 8373867: Improve robustness of Attach API for finding tmp directory Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/28867 From alanb at openjdk.org Sat Jan 17 08:27:11 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 08:27:11 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java line 72: > 70: * @param cause the cause of this exception. > 71: */ > 72: public AttachNotSupportedException(String message, Throwable cause) { This is an API change, it will need a CSR. It w ill also need `@since` tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2700771901 From ysuenaga at openjdk.org Sat Jan 17 08:51:10 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 17 Jan 2026 08:51:10 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> Message-ID: On Sat, 17 Jan 2026 08:23:24 GMT, Alan Bateman wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix line >> - Update copyright year > > src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java line 72: > >> 70: * @param cause the cause of this exception. >> 71: */ >> 72: public AttachNotSupportedException(String message, Throwable cause) { > > This is an API change, it will need a CSR. It w ill also need `@since` tag. I've already integrated this PR... Can I file to JBS as new issue for adding `@since`, and submit CSR for it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2700784093 From alanb at openjdk.org Sat Jan 17 09:00:38 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 09:00:38 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> Message-ID: On Sat, 17 Jan 2026 08:47:03 GMT, Yasumasa Suenaga wrote: >> src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java line 72: >> >>> 70: * @param cause the cause of this exception. >>> 71: */ >>> 72: public AttachNotSupportedException(String message, Throwable cause) { >> >> This is an API change, it will need a CSR. It w ill also need `@since` tag. > > I've already integrated this PR... > > Can I file to JBS as new issue for adding `@since`, and submit CSR for it? You'll need to create a retroactive CSR for JDK-8373867. You can fix the `@since` separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2700790062 From jbhateja at openjdk.org Sat Jan 17 11:42:32 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 17 Jan 2026 11:42:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> Message-ID: On Fri, 19 Dec 2025 22:48:50 GMT, Paul Sandoz wrote: >> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. >> Hi @eme64 , Kindly share your comments. > >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Same here! Hi @PaulSandoz , your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3763199964 From cjplummer at openjdk.org Sat Jan 17 18:17:04 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 17 Jan 2026 18:17:04 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped Message-ID: The support for locating zipped (and subsequently unzipped) core files broken when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: if (core_pattern[0] == '|') { written = jio_snprintf(buffer, bufferSize, - ""%s" (or dumping to %s/core.%d)", + ""%s" (alternatively, falling back to %s/core.%d)", &core_pattern[1], p, current_process_id()); CoreUtils was checking for "or ", but it needs to check for "alternatively...". Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. ------------- Commit messages: - fix whitespace - get rid of unnecessary throws clause - fix zipped core file support Changes: https://git.openjdk.org/jdk/pull/29284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29284&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375477 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29284/head:pull/29284 PR: https://git.openjdk.org/jdk/pull/29284 From cjplummer at openjdk.org Sat Jan 17 18:19:25 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 17 Jan 2026 18:19:25 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: > 260: if (isClassLoaderReclaimed()) { > 261: System.out.println("ClassUnloader: class loader has been reclaimed."); > 262: Runtime.getRuntime().gc(); It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2701332698 From ysuenaga at openjdk.org Sun Jan 18 05:43:27 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 18 Jan 2026 05:43:27 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> Message-ID: On Sat, 17 Jan 2026 08:56:59 GMT, Alan Bateman wrote: >> I've already integrated this PR... >> >> Can I file to JBS as new issue for adding `@since`, and submit CSR for it? > > You'll need to create a retroactive CSR for JDK-8373867. > > You can fix the `@since` separately. I filled CSR: https://bugs.openjdk.org/browse/JDK-8375582 I've already created [draft PR](https://github.com/openjdk/jdk/pull/29289). I will promote it to regular PR when the CSR is approved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2702133883 From jpai at openjdk.org Sun Jan 18 05:56:03 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Jan 2026 05:56:03 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> Message-ID: On Sun, 18 Jan 2026 05:40:56 GMT, Yasumasa Suenaga wrote: >> You'll need to create a retroactive CSR for JDK-8373867. >> >> You can fix the `@since` separately. > > I filled CSR: https://bugs.openjdk.org/browse/JDK-8375582 > > I've already created [draft PR](https://github.com/openjdk/jdk/pull/29289). I will promote it to regular PR when the CSR is approved. Hello @YaSuenag, the PR to add `@since 27` doesn't have to wait for the CSR. In fact, it would be good to have that `@since` change integrated soon to address the `test/jdk/tools/sincechecker/modules/jdk.attach/JdkAttachCheckSince.java` test that has been failing regularly in the CI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2702143810 From ysuenaga at openjdk.org Sun Jan 18 07:28:45 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 18 Jan 2026 07:28:45 GMT Subject: RFR: 8375575: AttachNotSupportedException constructor missing @since 27 Message-ID: The changes for [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) are missing `@since 27`. This PR makes trivial change to add it. ------------- Commit messages: - 8375575: AttachNotSupportedException constructor missing @since 27 Changes: https://git.openjdk.org/jdk/pull/29289/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29289&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375575 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29289/head:pull/29289 PR: https://git.openjdk.org/jdk/pull/29289 From ysuenaga at openjdk.org Sun Jan 18 07:28:47 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 18 Jan 2026 07:28:47 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> Message-ID: <_zxC2G5lOm5DsdxYTek03KuMxx55W84GLSeCzylnMuQ=.c966828b-60a5-443c-9199-ed5f1acd423d@github.com> On Sun, 18 Jan 2026 05:52:02 GMT, Jaikiran Pai wrote: >> I filled CSR: https://bugs.openjdk.org/browse/JDK-8375582 >> >> I've already created [draft PR](https://github.com/openjdk/jdk/pull/29289). I will promote it to regular PR when the CSR is approved. > > Hello @YaSuenag, the PR to add `@since 27` doesn't have to wait for the CSR. In fact, it would be good to have that `@since` change integrated soon to address the `test/jdk/tools/sincechecker/modules/jdk.attach/JdkAttachCheckSince.java` test that has been failing regularly in the CI. I marked RFR to #29289 for adding `@since 27`. I think it is trivial change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2702186997 From liach at openjdk.org Sun Jan 18 07:30:38 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 07:30:38 GMT Subject: RFR: 8375575: AttachNotSupportedException constructor missing @since 27 In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 05:39:44 GMT, Yasumasa Suenaga wrote: > The changes for [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) are missing `@since 27`. This PR makes trivial change to add it. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29289#pullrequestreview-3675298309 From ysuenaga at openjdk.org Sun Jan 18 07:39:04 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 18 Jan 2026 07:39:04 GMT Subject: Integrated: 8375575: AttachNotSupportedException constructor missing @since 27 In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 05:39:44 GMT, Yasumasa Suenaga wrote: > The changes for [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) are missing `@since 27`. This PR makes trivial change to add it. This pull request has now been integrated. Changeset: 1cdb8174 Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/1cdb8174220e52c055406e0e927bc982c91ac595 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8375575: AttachNotSupportedException constructor missing @since 27 Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/29289 From alanb at openjdk.org Sun Jan 18 08:03:10 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 Jan 2026 08:03:10 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year VirtualMachine.attach is specified to throw IOException and AttachNotSupportedException. Are you 100% sure that AttachNotSupportedException make sense to throw in this configuration? In the example I would expect attach to throw java.nio.file.AccessDeniedException (which is an IOException), not AttachNotSupportedException with the IOException as cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3765031314 From ysuenaga at openjdk.org Sun Jan 18 10:00:30 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 18 Jan 2026 10:00:30 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 07:58:48 GMT, Alan Bateman wrote: > Are you 100% sure that AttachNotSupportedException make sense to throw in this configuration? Yes. We don't know whether target process provides a compatible `AttachProvider` if Attach API could not access `/tmp` of target process. Target process might not be Java. So I think it makes sence to throw `AttachNotSupportedException` with the cause. The user get a hint from "Caused by" to check why Attach API failed. [08:40:27] ~/d/e/jdk ? pull/28867 ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version 52779: com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:292) at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:233) at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:84) at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) Caused by: java.nio.file.AccessDeniedException: /proc/52779/root/tmp at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113) at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391) at java.base/java.nio.file.Files.isSameFile(Files.java:1418) at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:277) ... 6 more ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3765121718 From alanb at openjdk.org Sun Jan 18 14:52:20 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 Jan 2026 14:52:20 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <3eEYv4VtmTaG0Bm0XKEkZLzkh6wPTTMbU2oZeQCzV2U=.656aa9c3-86da-47b8-9251-754270e5d793@github.com> On Sun, 18 Jan 2026 09:57:35 GMT, Yasumasa Suenaga wrote: > > Are you 100% sure that AttachNotSupportedException make sense to throw in this configuration? > > Yes. We don't know whether target process provides a compatible `AttachProvider` if Attach API could not access `/tmp` of target process. Target process might not be Java. So I think it makes sence to throw `AttachNotSupportedException` with the cause. The user get a hint from "Caused by" to check why Attach API failed. This is how we specified AttachNotSupportedException is specified: "Thrown by VirtualMachine.attach when attempting to attach to a Java virtual machine for which a compatible AttachProvider does not exist. It is also thrown by AttachProvider.attachVirtualMachine if the provider attempts to attach to a Java virtual machine with which it not compatible." When we introduced the attach API then the intention was to allow for other provider implementations so that the API could be used to attach to non-HotSpot VM. This is why VirtualMachine.attach iterates through the providers and attempts to attach each installed provider. Looking at it now, the JDK only includes one provider and it rare-to-never to have additional providers on the class path. In addition, it turns out to be "hard to impossible" for the HotSpot provider to distinguish non-HotSpot VM processes from environment/configuration/setup issues. I think it's a good time to re-visit this, maybe it is time to drop the throwing of AttachNotSupportedException as it's not helpful? In your example, the attach is failing and would be a lot clearer if it threw IOException (AccessDeniedException is an IOException) rather AttachNotSupportedException with the IOException as the cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3765371426 From lmesnik at openjdk.org Sun Jan 18 20:17:30 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 18 Jan 2026 20:17:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java line 109: > 107: > 108: while (thrd.isAlive()) { > 109: logger.display("Thread state: " + thrd.getState() Please add some sleep to don't produce huge amount of output. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 254: > 252: WhiteBox.getWhiteBox().fullGC(); > 253: int count = 0; > 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { Thanks for the fix. I find the same. The old unloading method triggered several GCs and took a lot of time. So might be this allowed all classes/method to freed and corresponding events to be generate. The method unloading event might be generated after full GC is completed. It is called on ServiceThread with some latency. And haven't time to check another events. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 256: > 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { > 255: System.out.println("ClassUnloader: waiting for class loader reclaiming... " + count); > 256: WhiteBox.getWhiteBox().fullGC(); Can you add some small delay (100ms) between attempts. To give more chances to process ojbects inside VM like jvmti deferred queue. ------------- PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3675260387 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702146837 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702691837 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702693051 From ysuenaga at openjdk.org Mon Jan 19 01:23:31 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 19 Jan 2026 01:23:31 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: <3eEYv4VtmTaG0Bm0XKEkZLzkh6wPTTMbU2oZeQCzV2U=.656aa9c3-86da-47b8-9251-754270e5d793@github.com> References: <3eEYv4VtmTaG0Bm0XKEkZLzkh6wPTTMbU2oZeQCzV2U=.656aa9c3-86da-47b8-9251-754270e5d793@github.com> Message-ID: <4tZjqTZR0vKkf_mo3Z4NzGNsuC4jGHXZHy2ASJyAaDE=.40b004cb-8cdb-44a1-94aa-1fade106b6e6@github.com> On Sun, 18 Jan 2026 14:48:13 GMT, Alan Bateman wrote: > In addition, it turns out to be hard-to-impossible" for the HotSpot provider to distinguish non-HotSpot VM processes from environment/configuration/setup issues. Agree. I uploaded the commit to go through IOE. What do you think? https://github.com/openjdk/jdk/commit/66a038afc45e957eb8194f1a715ed6044556df89 It still wraps exceptions from `MonitoredHost` because they are secondary exceptions at exception handler. But I'm ok if they should go through like IOE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3766015531 From dholmes at openjdk.org Mon Jan 19 01:57:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 01:57:36 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 I'm struggling to map code changes to the description of the changes. I think a lot more comments are needed to describe things more clearly. The three testcases need a clearer description - and '1' '2' '3' are not great names. Given we are in the SuspendWithObjectMonitorWait directory we do not need that prefix on all the file names - we can use shorter but more descriptive names for what is actually being tested. Thanks src/hotspot/share/runtime/objectMonitor.cpp line 1907: > 1905: // That is, we fail toward safety. > 1906: > 1907: was_notified = true; This isn't quite right. If we would reach line 1882 then we were not notified, so we cannot unconditionally set this to true here. I think you need to initialize to true at line 1868 and then set to false at line 1882 (deleting the current comment). src/hotspot/share/runtime/objectMonitor.cpp line 1917: > 1915: } > 1916: > 1917: // The thread is now either on off-list (TS_RUN), Suggestion: // The thread is now either off-list (TS_RUN), src/hotspot/share/runtime/objectMonitor.cpp line 1932: > 1930: // (Don't cache naked oops over safepoints, of course). > 1931: > 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. Suggestion: // Post monitor waited event. Note that this is past-tense, we are done waiting. You need to expand the comment to explain the significance of checking for TS_ENTER. src/hotspot/share/runtime/objectMonitor.cpp line 1967: > 1965: // We can go to a safepoint at the end of this block. If we > 1966: // do a thread dump during that safepoint, then this thread will show > 1967: // as having "-locked" the monitor, but the OS and java.lang.Thread To be clear, if it is a plain-old safepoint, we will show the monitor as locked because it is. But if it happens we were suspended, then we will release the monitor and so we wouldn't report locked. src/hotspot/share/runtime/objectMonitor.cpp line 1973: > 1971: // and set the OM as pending. > 1972: } > 1973: // Done waiting, post the corresponding event What event? I expected to see `JvmtiExport::post_monitor_waited` here. ?? src/hotspot/share/runtime/objectMonitor.cpp line 2053: > 2051: // Adding to _entry_list uses Atomic::cmpxchg() which already provides > 2052: // a fence that prevents reordering of the stores. > 2053: if (!JvmtiExport::should_post_monitor_waited()) { You need to explain why this is now conditional. src/hotspot/share/runtime/objectMonitor.cpp line 2063: > 2061: if (!JvmtiExport::should_post_monitor_waited()) { > 2062: add_to_entry_list(current, iterator); > 2063: } else { You need to explain what each of these paths is doing. At this point I'm lost. src/hotspot/share/runtime/objectMonitor.cpp line 2069: > 2067: > 2068: oop vthread = nullptr; > 2069: ParkEvent* Trigger; I assume this is copied from elsewhere but we should use proper style rules in the new code i.e. local variables don't start with a capital. Thanks. Also "trigger" doesn't really convet anythng meaningful to me - `evt` for event seems fine. src/hotspot/share/runtime/objectMonitor.cpp line 2277: > 2275: node->_at_reenter = true; > 2276: > 2277: if (state == ObjectWaiter::TS_RUN) { I'm finding the changes to `was_notified` versus use of explicit state checks very confusing. I keep asking myself which state means I was notified and which does not. test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 71: > 69: public int doWork1(int timeMax, PrintStream out) { > 70: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread > 71: SuspendWithObjectMonitorWaitWorker resumer; // resumer thread Suggestion: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread SuspendWithObjectMonitorWaitWorker resumer; // resumer thread ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3675924710 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702902497 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702905495 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702909290 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702947656 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702958092 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702960742 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702965432 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702967605 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702974131 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702975301 From lmesnik at openjdk.org Mon Jan 19 02:18:36 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 19 Jan 2026 02:18:36 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 03:49:17 GMT, Chris Plummer wrote: > The support for locating zipped (and subsequently unzipped) core files broken when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: > > > if (core_pattern[0] == '|') { > written = jio_snprintf(buffer, bufferSize, > - ""%s" (or dumping to %s/core.%d)", > + ""%s" (alternatively, falling back to %s/core.%d)", > &core_pattern[1], p, current_process_id()); > > > CoreUtils was checking for "or ", but it needs to check for "alternatively...". > > Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29284#pullrequestreview-3676030589 From syan at openjdk.org Mon Jan 19 06:57:13 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 06:57:13 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 SendaoYan has updated the pull request incrementally with one additional commit since the last revision: 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29285/files - new: https://git.openjdk.org/jdk/pull/29285/files/7b6daf35..4f3d03a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=00-01 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From syan at openjdk.org Mon Jan 19 07:05:30 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 07:05:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 05:59:58 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java line 109: > >> 107: >> 108: while (thrd.isAlive()) { >> 109: logger.display("Thread state: " + thrd.getState() > > Please add some sleep to don't produce huge amount of output. Fixed. > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 256: > >> 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { >> 255: System.out.println("ClassUnloader: waiting for class loader reclaiming... " + count); >> 256: WhiteBox.getWhiteBox().fullGC(); > > Can you add some small delay (100ms) between attempts. To give more chances to process ojbects inside VM like jvmti deferred queue. Thanks for the suggestion. Thread.sleep(100) has been added after WB.fullgc(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703461267 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703463604 From syan at openjdk.org Mon Jan 19 07:14:06 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 07:14:06 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 18:15:50 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: > >> 260: if (isClassLoaderReclaimed()) { >> 261: System.out.println("ClassUnloader: class loader has been reclaimed."); >> 262: Runtime.getRuntime().gc(); > > It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? This gc() seems meaningless but is harmless. Should we remove this gc() call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703487032 From alanb at openjdk.org Mon Jan 19 08:35:21 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jan 2026 08:35:21 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: <_zxC2G5lOm5DsdxYTek03KuMxx55W84GLSeCzylnMuQ=.c966828b-60a5-443c-9199-ed5f1acd423d@github.com> References: <7rl6XNPB7ACuJrli4HTLruDgxUXPaxF4NiUGYRpucQM=.17382c22-f83b-4140-bd03-4ebce823c3b7@github.com> <_zxC2G5lOm5DsdxYTek03KuMxx55W84GLSeCzylnMuQ=.c966828b-60a5-443c-9199-ed5f1acd423d@github.com> Message-ID: On Sun, 18 Jan 2026 07:25:20 GMT, Yasumasa Suenaga wrote: > I marked RFR to #29289 for adding `@since 27`. I think it is trivial change. Can you change findTargetProcessTmpDirectory to that it throws IOException, not AttachNotSupportedException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2703742452 From aartemov at openjdk.org Mon Jan 19 08:41:49 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 08:41:49 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v21] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed year in the copyright. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Removed ClearSuccOnSuspend - 8366659: Fixed liveness problem. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed build problem. - 8366659: Fixed build issue. - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - ... and 35 more: https://git.openjdk.org/jdk/compare/75172e06...03932cc5 ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=20 Stats: 1331 lines in 9 files changed: 882 ins; 417 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From alanb at openjdk.org Mon Jan 19 08:45:13 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jan 2026 08:45:13 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <54Gk7EgxB8iYaLk_2zg9zXhhfhH54Axd06NahEc4Qqw=.b963a1a9-b2bc-4451-a08c-f799f1d29819@github.com> On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year > Agree. I uploaded the commit to go through IOE. What do you think? [66a038a](https://github.com/openjdk/jdk/commit/66a038afc45e957eb8194f1a715ed6044556df89) > > It still wraps exceptions from `MonitoredHost` because they are secondary exceptions at exception handler. But I'm ok if they should go through like IOE. Can you try removing all of the catching of IOException from findTargetProcessTmpDirectory and provide a summary of the exceptions you get for the various scenarios. TBH, something is not right if we end up with AttachNotSupportedException and an IOException as cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3767116049 From aartemov at openjdk.org Mon Jan 19 09:57:10 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 09:57:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v22] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Modified comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/03932cc5..95cf01f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=20-21 Stats: 14 lines in 1 file changed: 0 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Mon Jan 19 09:57:11 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 09:57:11 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v21] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:07:22 GMT, Daniel D. Daugherty wrote: > Sorry for the long delay in getting back to this review. > > There a comment in ObjectMonitor::wait() that I think might be incorrect. See L1965 -> L1969 in src/hotspot/share/runtime/objectMonitor.cpp. > > I really like the refactoring that you've done with the test! > > Thumbs up on the code and most of the comments. I think that part of the comment dates back to 2014 commit, when there was no `ExitOnSuspend` trick, and it seems that the comment is no longer valid. I modified in both places where we use the trick, one in `wait()`, and another one in `enter_with_contention_mark()`, because they are the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3767425019 From aartemov at openjdk.org Mon Jan 19 10:10:39 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 10:10:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v23] In-Reply-To: References: Message-ID: <_g0m2zvkitzl9ztwzc45eiDfmGdjjNHP8OARjTMW8XU=.454d98a8-4fb8-4cbb-bc8e-e28654f1eab6@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Modified the comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/95cf01f6..949db95e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=21-22 Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Mon Jan 19 10:10:44 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 10:10:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 01:19:44 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - 8366659: Fixed year in the copyright. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed ClearSuccOnSuspend >> - 8366659: Fixed liveness problem. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed build problem. >> - 8366659: Fixed build issue. >> - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed semi-broken tests >> - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 > > src/hotspot/share/runtime/objectMonitor.cpp line 1967: > >> 1965: // We can go to a safepoint at the end of this block. If we >> 1966: // do a thread dump during that safepoint, then this thread will show >> 1967: // as having "-locked" the monitor, but the OS and java.lang.Thread > > To be clear, if it is a plain-old safepoint, we will show the monitor as locked because it is. But if it happens we were suspended, then we will release the monitor and so we wouldn't report locked. I added clarification at the end of the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704080984 From ysuenaga at openjdk.org Mon Jan 19 10:58:49 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 19 Jan 2026 10:58:49 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year I think we cannot remove `catch` for IOException because it is used for fallback code. I added numbers as comment to the code to explain: try { if (Files.isWritable(tmpOnProcPidRoot)) { return tmpOnProcPidRoot.toString(); } else if (Files.isSameFile(tmpOnProcPidRoot, TMPDIR)) { // <- (1) return TMPDIR.toString(); } else { throw new AttachNotSupportedException("Unable to access the filesystem of the target process"); // <- (2) } } catch (IOException ioe) { try { boolean found = MonitoredHost.getMonitoredHost("//localhost") .activeVms() .stream() .anyMatch(i -> pid == i.intValue()); if (found) { // We can use /tmp because target process is on same host // even if we cannot access /proc//root. // The process with capsh/setcap would fall this pattern. return TMPDIR.toString(); } // Throw original IOE if target process not found on localhost. throw ioe; // <- (3) } catch (MonitorException | URISyntaxException e) { // <- (4) // Other exceptions (happened at MonitoredHost) would be wrapped with AttachNotSupportedException throw new AttachNotSupportedException("Unable to find target proces", e); } } 1. AccessDeniedException might be thrown if the process is not granted to access the path. In addition, other exceptions which inherits IOException would be thrown I/O error (e.g. disconnection of network file system) 2. If `/proc//root/tmp` is not writable and it is different from `/tmp`, AttachNotSupportedException is thrown. It would be happened in container, or jailed process (chroot). I think that target process can be considered to be running in an environment that does not support Attach API. 3. If IOException is happened at `Files.isSame()`, Attach API attempts to check whether target process (PID) is listed in active VMs in `MonitoredHost`. Throws original IOException if not. 4. Methods in `MonitoredHost` might throw `MonitorException` or `URISyntaxException`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3767711293 From aartemov at openjdk.org Mon Jan 19 11:18:22 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 11:18:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewers' comments, added comments, renamed tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/949db95e..0fd6bc7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=22-23 Stats: 53 lines in 5 files changed: 21 ins; 4 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Mon Jan 19 11:18:32 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 11:18:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 00:27:39 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - 8366659: Fixed year in the copyright. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed ClearSuccOnSuspend >> - 8366659: Fixed liveness problem. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed build problem. >> - 8366659: Fixed build issue. >> - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed semi-broken tests >> - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 > > src/hotspot/share/runtime/objectMonitor.cpp line 1907: > >> 1905: // That is, we fail toward safety. >> 1906: >> 1907: was_notified = true; > > This isn't quite right. If we would reach line 1882 then we were not notified, so we cannot unconditionally set this to true here. I think you need to initialize to true at line 1868 and then set to false at line 1882 (deleting the current comment). Thanks for spotting this! Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1917: > >> 1915: } >> 1916: >> 1917: // The thread is now either on off-list (TS_RUN), > > Suggestion: > > // The thread is now either off-list (TS_RUN), Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1932: > >> 1930: // (Don't cache naked oops over safepoints, of course). >> 1931: >> 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. > > Suggestion: > > // Post monitor waited event. Note that this is past-tense, we are done waiting. > > You need to expand the comment to explain the significance of checking for TS_ENTER. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1973: > >> 1971: // and set the OM as pending. >> 1972: } >> 1973: // Done waiting, post the corresponding event > > What event? I expected to see `JvmtiExport::post_monitor_waited` here. ?? I think I overlooked this comment, it is related to one of the previous iterations, where the `JvmtiExport::post_monitor_waited` event was posted further down in the code. Removed. > src/hotspot/share/runtime/objectMonitor.cpp line 2053: > >> 2051: // Adding to _entry_list uses Atomic::cmpxchg() which already provides >> 2052: // a fence that prevents reordering of the stores. >> 2053: if (!JvmtiExport::should_post_monitor_waited()) { > > You need to explain why this is now conditional. Added a comment there. > src/hotspot/share/runtime/objectMonitor.cpp line 2063: > >> 2061: if (!JvmtiExport::should_post_monitor_waited()) { >> 2062: add_to_entry_list(current, iterator); >> 2063: } else { > > You need to explain what each of these paths is doing. At this point I'm lost. Added extended comments for both cases. > src/hotspot/share/runtime/objectMonitor.cpp line 2069: > >> 2067: >> 2068: oop vthread = nullptr; >> 2069: ParkEvent* Trigger; > > I assume this is copied from elsewhere but we should use proper style rules in the new code i.e. local variables don't start with a capital. Thanks. Also "trigger" doesn't really convet anythng meaningful to me - `evt` for event seems fine. Right, it was copied from some other file. Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 2277: > >> 2275: node->_at_reenter = true; >> 2276: >> 2277: if (state == ObjectWaiter::TS_RUN) { > > I'm finding the changes to `was_notified` versus use of explicit state checks very confusing. I keep asking myself which state means I was notified and which does not. Yes, it is all because unparking inside of `notify_internal()`, which is needed to fix the problem, leads to threads which have been actually notified (aka woken up in `notify_internal()'), but are not on the `entry_list`. We may need to do a follow-up PR with some refactoring, maybe binary state is not sufficient. > test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 71: > >> 69: public int doWork1(int timeMax, PrintStream out) { >> 70: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread >> 71: SuspendWithObjectMonitorWaitWorker resumer; // resumer thread > > Suggestion: > > SuspendWithObjectMonitorWaitWorker waiter; // waiter thread > SuspendWithObjectMonitorWaitWorker resumer; // resumer thread Fixed in all test cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704328783 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704329246 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704329583 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330248 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330507 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330740 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330960 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704331400 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704331637 From kfarrell at openjdk.org Mon Jan 19 11:25:41 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 19 Jan 2026 11:25:41 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v8] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/bb3b243c..2b1de0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06-07 Stats: 57 lines in 1 file changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From alanb at openjdk.org Mon Jan 19 11:50:09 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jan 2026 11:50:09 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year AttachNotSupportedException should not be thrown when attaching fails due to file permission issues. Can you change these changes to throw IOException and see what is left? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3767933621 From epeter at openjdk.org Mon Jan 19 16:10:04 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:10:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Including test changes from Bhavana Kilambi (ARM) > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e @jatin-bhateja I had a quick look at some of the changes. The patch is HUGE (80k+ lines), so it will take me a bit more time to review. I also realized that quite some changes are not directly related. For example, you are renaming lots of existing files. I would prefer if those changes were done separately. The issue is that at some point GitHub chokes, and it is no fun doing the review :/ src/hotspot/share/opto/vectorIntrinsics.cpp line 2895: > 2893: opd1 = gvn().transform(VectorNode::make(Op_AndV, opd1, wrap_mask_vec, opd1->bottom_type()->is_vect())); > 2894: operation = gvn().transform(VectorNode::make(Op_SelectFromTwoVector, opd1, opd2, opd3, vt)); > 2895: VectorNode::trace_new_vector(operation, "VectorAPI"); I thought you wanted to add that in a separate RFE? src/hotspot/share/prims/vectorSupport.cpp line 206: > 204: } > 205: > 206: int VectorSupport::vop2ideal(jint id, int lane_type) { I think it would be nice if there was a name for `LaneType`. It's just nicer to have types named. After all, the code here used to use `BasicType`, and it helps the user know what is expected here. src/hotspot/share/prims/vectorSupport.cpp line 244: > 242: case T_FLOAT: return Op_MulF; > 243: case T_DOUBLE: return Op_MulD; > 244: default: fatal("MUL: %s", lanetype2name(lane_type)); You should fix the indentation here as well, since you are already doing it everywhere else ;) src/hotspot/share/utilities/globalDefinitions.hpp line 719: > 717: > 718: inline bool is_java_primitive(BasicType t) { > 719: return (t != T_FLOAT16 && T_BOOLEAN <= t && t <= T_LONG); This change seems unnecessary, right? `T_FLOAT16` is outside the range, as far as I can see. src/hotspot/share/utilities/globalDefinitions.hpp line 741: > 739: inline bool is_custom_basic_type(BasicType t) { > 740: return (t == T_FLOAT16); > 741: } What exactly is the definition of a "custom" basic type? Is it defined somewhere? If not, it would be useful to define it here. I assume you chose the name because we expect more such "custom" basic types in the future? ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3678699226 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705309070 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705323981 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705316085 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705333596 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705291064 From epeter at openjdk.org Mon Jan 19 16:19:02 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:19:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Including test changes from Bhavana Kilambi (ARM) > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); > 67: > 68: static void AssertEquals(int actual, int expected) { There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705376899 From kevinw at openjdk.org Mon Jan 19 17:34:34 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 19 Jan 2026 17:34:34 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:19:37 GMT, Kieran Farrell wrote: >> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. >> >> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. > > Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'openjdk:master' into JDK_8359706 > - comment > - timed loop for aix and linux proc read > - rm unused variables > - updates > - clean up > - clean up > - undo commit to linux.cpp > - rm max count and malloc > - bsd.cpp > - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255 Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? Would it be a better fit in the "OS:" section which is where we show e.g. limit information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3769485949 From lmesnik at openjdk.org Mon Jan 19 18:56:18 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 19 Jan 2026 18:56:18 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:10:15 GMT, SendaoYan wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: >> >>> 260: if (isClassLoaderReclaimed()) { >>> 261: System.out.println("ClassUnloader: class loader has been reclaimed."); >>> 262: Runtime.getRuntime().gc(); >> >> It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? > > This gc() seems meaningless but is harmless. Should we remove this gc() call. I think it could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2705807447 From kfarrell at openjdk.org Mon Jan 19 21:10:35 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 19 Jan 2026 21:10:35 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:31:10 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge branch 'openjdk:master' into JDK_8359706 >> - comment >> - timed loop for aix and linux proc read >> - rm unused variables >> - updates >> - clean up >> - clean up >> - undo commit to linux.cpp >> - rm max count and malloc >> - bsd.cpp >> - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255 > > Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? > > It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? > > Would it be a better fit in the "OS:" section which is where we show e.g. limit information. Hi @kevinjwalls, here is a snippit from the current position under "PROCESS". I added it here since the count is process related but I agree it might be nice to have it closer to the NOFILE count int the "OS" section under "SYSTEM". --------------- P R O C E S S --------------- Heap address: 0x0000000320000000, size: 9216 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 CDS archive(s) not mapped Compressed class space mapped at: 0x00000fc000000000-0x00000fc040000000, reserved size: 1073741824 UseCompressedClassPointers 1, UseCompactObjectHeaders 0 Narrow klass pointer bits 32, Max shift 3 Narrow klass base: 0x00000fc000000000, Narrow klass shift: 0 Encoding Range: [0x00000fc000000000 - 0x00000fc100000000), (4294967296 bytes) Klass Range: [0x00000fc000000000 - 0x00000fc040000000), (1073741824 bytes) Klass ID Range: [8 - 1073741817) (1073741809) Protection zone: [0x00000fc000000000 - 0x00000fc000010000), (65536 bytes) OpenFileDescriptorCount = 5 GC Precious Log: CardTable entry size: 512 Card Set container configuration: InlinePtr #cards 4 size 8 Array Of Cards #cards 64 size 144 Howl #buckets 8 coarsen threshold 14745 Howl Bitmap #cards 2048 size 272 coarsen threshold 1843 Card regions per heap region 1 cards per card region 16384 CPUs: 11 total, 11 available Memory: 36864M Large Page Support: Disabled NUMA Support: Disabled Compressed Oops: Enabled (Zero based) Heap Region Size: 8M Heap Min Capacity: 8M Heap Initial Capacity: 8M Heap Max Capacity: 9G Pre-touch: Disabled Parallel Workers: 9 Concurrent Workers: 2 Concurrent Refinement Workers: 9 Periodic GC: Disabled Heap: garbage-first heap total reserved 9437184K, committed 8192K, used 4545K [0x0000000320000000, 0x0000000560000000) region size 8M, 1 eden (8M), 0 survivor (0M), 0 old (0M), 0 humongous (0M), 0 free (0M) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3770120194 From ysuenaga at openjdk.org Tue Jan 20 00:05:23 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 20 Jan 2026 00:05:23 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:48:06 GMT, Alan Bateman wrote: > AttachNotSupportedException should not be thrown when attaching fails due to file permission issues. Did you say about scenario (2) in above? Then it is not file permission issue. For example, `/tmp` is different between container instances. In scenario (4), the user is different between target process and attacher process (if it runs as non-root). IMO we might use IOE in (2) because the problem is filesystem reachability, but (4) should not be IOE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3770485977 From dholmes at openjdk.org Tue Jan 20 00:14:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 00:14:27 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:14:41 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1932: >> >>> 1930: // (Don't cache naked oops over safepoints, of course). >>> 1931: >>> 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. >> >> Suggestion: >> >> // Post monitor waited event. Note that this is past-tense, we are done waiting. >> >> You need to expand the comment to explain the significance of checking for TS_ENTER. > > Addressed. You didn't expand the comment. IIUC if the state is TS_ENTER then we were notified and moved from TS_WAIT to TS_ENTER before being unparked. But, again IIUC, that will only happen if we don't have to post the event else the notification will unpark us directly and move us to TS_RUN. Which means that checking `!= TS_ENTER` is redundant because if we should post the event then we can't be in state TS_ENTER. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706361996 From dholmes at openjdk.org Tue Jan 20 00:52:12 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 00:52:12 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:18:22 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments, added comments, renamed tests. Thanks for the updates. A few follow ups and queries. src/hotspot/share/runtime/objectMonitor.cpp line 2055: > 2053: // This is is now conditional as if the monitor_waited even > 2054: // is allowed, then a thread, even virtual, should not be moved to > 2055: // the entry_list, but rather unparked and let run. See the comment below. Suggestion: // If we will add the vthread to the entry list below then we need to // increment the counter *before* doing so. // Adding to _entry_list uses Atomic::cmpxchg() which already provides // a fence that prevents reordering of the stores. if (!JvmtiExport::should_post_monitor_waited()) { src/hotspot/share/runtime/objectMonitor.cpp line 2066: > 2064: // If the monitor_waited JVMTI event is not allowed, a thread is > 2065: // transferred to the entry_list, and it will eventually be unparked > 2066: // only when it is chosen to become a successor. Suggestion: // only when it is chosen to become the successor. src/hotspot/share/runtime/objectMonitor.cpp line 2077: > 2075: // avoid a problem of having a suspension point when posting > 2076: // the monitor_waited JVMTI event, as suspending such a thread > 2077: // is no harm. Suggestion: // However, if the monitor_waited event is allowed, then // the thread is set to state TS_RUN and unparked. The thread // will then contend directly to reacquire the monitor and // avoids being flagged as the successor. This avoids the problem // of having a thread suspend whilst it is the successor. src/hotspot/share/runtime/objectMonitor.cpp line 2103: > 2101: evt->unpark(); > 2102: } > 2103: else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { Suggestion: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { src/hotspot/share/runtime/objectMonitor.cpp line 2296: > 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. > 2295: if (state == ObjectWaiter::TS_RUN) { > 2296: bool acquired = vthread_monitor_enter(current, node); If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3679921028 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706376692 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706377771 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706384082 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706385541 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706403647 From syan at openjdk.org Tue Jan 20 02:21:38 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 02:21:38 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [x] All tests touched test by JDK-8373945 with relase build > - [ ] All tests touched test by JDK-8373945 with fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary runtime.gc() afer classloader has been reclaimed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29285/files - new: https://git.openjdk.org/jdk/pull/29285/files/4f3d03a8..a561edc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From syan at openjdk.org Tue Jan 20 02:21:38 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 02:21:38 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: <3i1Aks_Y9yU4SjTB_-jBk-R6CgDREh9Ec4Gl-eFniuE=.601d8565-42bd-41b9-93af-ed55d3b1693a@github.com> On Mon, 19 Jan 2026 18:52:28 GMT, Leonid Mesnik wrote: >> This gc() seems meaningless but is harmless. Should we remove this gc() call. > > I think it could be removed. The Runtime.gc() has been removed. And all the touched tests related JDK-8373945 run passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2706520709 From lmesnik at openjdk.org Tue Jan 20 06:06:30 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Jan 2026 06:06:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> On Tue, 20 Jan 2026 02:21:38 GMT, SendaoYan wrote: >> Hi all, >> >> This PR make 2 changes which make test more rubustness: >> >> 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. >> 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. >> >> Additional testing: >> >> - [x] All tests touched test by JDK-8373945 with relase build >> - [ ] All tests touched test by JDK-8373945 with fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary runtime.gc() afer classloader has been reclaimed Thanks for addressing all the feedback. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3680475503 From duke at openjdk.org Tue Jan 20 08:57:52 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 08:57:52 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk 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 15 additional commits since the last revision: - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - introduce -T as a commong flag - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - ... and 5 more: https://git.openjdk.org/jdk/compare/d1597314...5f1cefe0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/bfa2a927..5f1cefe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00-01 Stats: 648983 lines in 8151 files changed: 439394 ins; 124768 del; 84821 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From aartemov at openjdk.org Tue Jan 20 09:04:07 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:04:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:49:19 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments, added comments, renamed tests. > > src/hotspot/share/runtime/objectMonitor.cpp line 2296: > >> 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. >> 2295: if (state == ObjectWaiter::TS_RUN) { >> 2296: bool acquired = vthread_monitor_enter(current, node); > > If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. The else clause at line 2312 pairs with `if (state == ObjectWaiter::TS_RUN)` statement, there are only two possibilities, either TS_RUN, or TS_ENTER, the latter implies that the thread is on the `entry_list`. If `acquired` is false when handling TS_RUN case, it is fine, the whole method will return false at line 2316. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707399555 From aartemov at openjdk.org Tue Jan 20 09:49:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v25] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/0fd6bc7d..594b8769 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=23-24 Stats: 16 lines in 1 file changed: 2 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Tue Jan 20 09:49:42 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:42 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:12:20 GMT, David Holmes wrote: >> Addressed. > > You didn't expand the comment. IIUC if the state is TS_ENTER then we were notified and moved from TS_WAIT to TS_ENTER before being unparked. But, again IIUC, that will only happen if we don't have to post the event else the notification will unpark us directly and move us to TS_RUN. Which means that checking `!= TS_ENTER` is redundant because if we should post the event then we can't be in state TS_ENTER. Sorry for missing that. Yes, you are right, it is redundant, as `JvmtiExport::should_post_monitor_waited()` is mutually exclusive with being in the `TS_ENTER` state now. I added this to the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707570006 From aartemov at openjdk.org Tue Jan 20 09:49:47 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:25:18 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments, added comments, renamed tests. > > src/hotspot/share/runtime/objectMonitor.cpp line 2055: > >> 2053: // This is is now conditional as if the monitor_waited even >> 2054: // is allowed, then a thread, even virtual, should not be moved to >> 2055: // the entry_list, but rather unparked and let run. See the comment below. > > Suggestion: > > // If we will add the vthread to the entry list below then we need to > // increment the counter *before* doing so. > // Adding to _entry_list uses Atomic::cmpxchg() which already provides > // a fence that prevents reordering of the stores. > if (!JvmtiExport::should_post_monitor_waited()) { Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2066: > >> 2064: // If the monitor_waited JVMTI event is not allowed, a thread is >> 2065: // transferred to the entry_list, and it will eventually be unparked >> 2066: // only when it is chosen to become a successor. > > Suggestion: > > // only when it is chosen to become the successor. Thanks for spotting, addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2077: > >> 2075: // avoid a problem of having a suspension point when posting >> 2076: // the monitor_waited JVMTI event, as suspending such a thread >> 2077: // is no harm. > > Suggestion: > > // However, if the monitor_waited event is allowed, then > // the thread is set to state TS_RUN and unparked. The thread > // will then contend directly to reacquire the monitor and > // avoids being flagged as the successor. This avoids the problem > // of having a thread suspend whilst it is the successor. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2103: > >> 2101: evt->unpark(); >> 2102: } >> 2103: else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { > > Suggestion: > > } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { Fixed in the lates commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707568773 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707568292 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707567423 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707566675 From aartemov at openjdk.org Tue Jan 20 09:56:09 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:56:09 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Fixed whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/594b8769..f672d155 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From duke at openjdk.org Tue Jan 20 10:07:19 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 10:07:19 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/e1bc2481...5f1cefe0 I've made timestamping optional with "-T" flag. The flag is part of the command sent to the target JVM. jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ The target diagnostic command handler can decide how to act on it. @dholmes-ora > ... what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? > And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). `Thread.print` already prints a timestamp, hence explicit "-T" has no effect for this particular command. This also affected my choice for using format "yyyy-MM-dd HH:mm:ss". At least as a default. Do you think we need to be able changing the timestamp format (say "-T=UTC")? Should we add time-stamping to STDOUT from commands that are of "action" type? E.g. "GC.run". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3772022851 From alanb at openjdk.org Tue Jan 20 10:49:36 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jan 2026 10:49:36 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <3DzZ5qZ4qD9ClEFBNL1b9BaJ3gr7IPKYRqFaBpEqMwo=.51518899-6df6-4efd-a822-4a314d92a91b@github.com> On Tue, 20 Jan 2026 00:01:33 GMT, Yasumasa Suenaga wrote: > IMO we might use IOE in (2) because the problem is filesystem reachability, but (4) should not be IOE. AttachNotSupportedException was intended to be thrown when attempting to attach to a Java virtual machine for which a compatible AttachProvider does not exist. I don't think any of the cases are in that bucket so should be okay to throw IOException for all these cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3772217076 From sgehwolf at openjdk.org Tue Jan 20 11:37:16 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 11:37:16 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name Message-ID: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. Thoughts? **Testing:** - [x] GHA - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. ------------- Commit messages: - 8375692: Hotspot container tests assert with non-ascii vendor name Changes: https://git.openjdk.org/jdk/pull/29315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375692 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From dholmes at openjdk.org Tue Jan 20 11:47:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 11:47:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:01:47 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 2296: >> >>> 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. >>> 2295: if (state == ObjectWaiter::TS_RUN) { >>> 2296: bool acquired = vthread_monitor_enter(current, node); >> >> If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. > > The else clause at line 2312 pairs with `if (state == ObjectWaiter::TS_RUN)` statement, there are only two possibilities, either TS_RUN, or TS_ENTER, the latter implies that the thread is on the `entry_list`. > > If `acquired` is false when handling TS_RUN case, it is fine, the whole method will return false at line 2316. Sorry misread the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2708005515 From syan at openjdk.org Tue Jan 20 11:52:03 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 11:52:03 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { > 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; > 380: } Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708015583 From jbhateja at openjdk.org Tue Jan 20 11:56:16 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:16 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/273b219e..fe7075ee Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=11-12 Stats: 85 lines in 4 files changed: 0 ins; 3 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Tue Jan 20 11:56:19 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:19 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:49:49 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Fix incorrect argument passed to smokeTest >> - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Including test changes from Bhavana Kilambi (ARM) >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Optimizing tail handling >> - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e > > src/hotspot/share/utilities/globalDefinitions.hpp line 741: > >> 739: inline bool is_custom_basic_type(BasicType t) { >> 740: return (t == T_FLOAT16); >> 741: } > > What exactly is the definition of a "custom" basic type? Is it defined somewhere? > If not, it would be useful to define it here. > > I assume you chose the name because we expect more such "custom" basic types in the future? You are right, primarily basic types are driven by JVM language specification...in this case T_FLOAT16 is a non standard basic type. > test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > >> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >> 67: >> 68: static void AssertEquals(int actual, int expected) { > > There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708024220 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708023788 From kevinw at openjdk.org Tue Jan 20 12:05:13 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 12:05:13 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:31:10 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge branch 'openjdk:master' into JDK_8359706 >> - comment >> - timed loop for aix and linux proc read >> - rm unused variables >> - updates >> - clean up >> - clean up >> - undo commit to linux.cpp >> - rm max count and malloc >> - bsd.cpp >> - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255 > > Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? > > It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? > > Would it be a better fit in the "OS:" section which is where we show e.g. limit information. > Hi @kevinjwalls, here is a snippit from the current position under "PROCESS". I added it here since the count is process related but I agree it might be nice to have it closer to the NOFILE count int the "OS" section under "SYSTEM". Thanks - yes, if we can group it more logically then I think more humans should discover it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3772524229 From sgehwolf at openjdk.org Tue Jan 20 13:34:27 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 13:34:27 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:48:49 GMT, SendaoYan wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > >> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >> 380: } > > Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Sure. I can do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708370629 From ysuenaga at openjdk.org Tue Jan 20 14:12:11 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 20 Jan 2026 14:12:11 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <_bNBzQJMwimp4b7OpswZk8TqkzVSvJO6AxKMyJ0GiEM=.20755909-0ee0-42ea-826c-559c1f676ad8@github.com> On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year I feel it is strange to throw IOE in case (4): } catch (MonitorException | URISyntaxException e) { // <- (4) // Other exceptions (happened at MonitoredHost) would be wrapped with AttachNotSupportedException throw new AttachNotSupportedException("Unable to find target proces", e); } If AttachNotSupportedException does not fit in this case, should we use RuntimeException or any other runtime exceptions here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3773067054 From alanb at openjdk.org Tue Jan 20 14:23:34 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jan 2026 14:23:34 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: <_bNBzQJMwimp4b7OpswZk8TqkzVSvJO6AxKMyJ0GiEM=.20755909-0ee0-42ea-826c-559c1f676ad8@github.com> References: <_bNBzQJMwimp4b7OpswZk8TqkzVSvJO6AxKMyJ0GiEM=.20755909-0ee0-42ea-826c-559c1f676ad8@github.com> Message-ID: On Tue, 20 Jan 2026 14:08:30 GMT, Yasumasa Suenaga wrote: > If AttachNotSupportedException does not fit in this case, should we use RuntimeException or any other runtime exceptions here? It's okay to throw IOException with a cause here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3773117248 From kevinw at openjdk.org Tue Jan 20 14:55:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 14:55:39 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/df6de4c1...5f1cefe0 Lots of duplication in the execute methods, of the same common condition around calling print_local_time... That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. Or separately in David's note earlier: "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773270519 From duke at openjdk.org Tue Jan 20 15:58:46 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:58:46 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 14:51:27 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/438fc675...5f1cefe0 > > Lots of duplication in the execute methods, of the same common condition around calling print_local_time... > That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. > (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") > > > To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. > > > Or separately in David's note earlier: > "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." > This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). @kevinjwalls I have created a v2 MR that handles timestamp in `DCmd::Executor::parse_and_execute` and doesn't change the executors. https://github.com/openjdk/jdk/pull/29325 The drawback is that timestamp can be printed twice in case of `Thread.print` diagnostic command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773628920 From duke at openjdk.org Tue Jan 20 15:59:41 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:59:41 GMT Subject: RFR: 8357828: add timestamp to jcmd v2 Message-ID: `jcmd` provides great diagnostics but many commands lack a timestamp in their output. Adding a timestamp to the output of some would add value for those debugging JVM data. With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ This is a simplified approach to handle timestamp (v1 is [here](https://github.com/openjdk/jdk/pull/27368)) Some diagnostic commands already provide timestamps information. For example `Thread.print` already starts with a timestamp of "yyyy-MM-dd HH:mm:ss" format. In that case the timestamp is printed twice if "-T" flag is passed to `Thread.print`. ------------- Commit messages: - improve TestJcmdTimestamp.java. add '-f - implementation v2, top level timestamping - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - ... and 7 more: https://git.openjdk.org/jdk/compare/f2d5290c...eaea764d Changes: https://git.openjdk.org/jdk/pull/29325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357828 Stats: 189 lines in 6 files changed: 169 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29325/head:pull/29325 PR: https://git.openjdk.org/jdk/pull/29325 From kfarrell at openjdk.org Tue Jan 20 16:56:11 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 16:56:11 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: > Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. > > This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: relocate print out to SYSTEM section and remove AIX impl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27971/files - new: https://git.openjdk.org/jdk/pull/27971/files/1f34d255..14ca2e29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=05-06 Stats: 60 lines in 4 files changed: 5 ins; 46 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971 PR: https://git.openjdk.org/jdk/pull/27971 From sgehwolf at openjdk.org Tue Jan 20 16:57:26 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:26 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/73bad7f9..9f93451f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Tue Jan 20 16:57:29 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 13:30:43 GMT, Severin Gehwolf wrote: >> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: >> >>> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >>> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >>> 380: } >> >> Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java > > Sure. I can do that. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/9f93451faae3e4f168386e7367ba75c54797deb7 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2709230655 From kevinw at openjdk.org Tue Jan 20 17:18:17 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 17:18:17 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 16:56:11 GMT, Kieran Farrell wrote: >> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. >> >> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > relocate print out to SYSTEM section and remove AIX impl src/hotspot/os/linux/os_linux.cpp line 2098: > 2096: > 2097: os::print_open_file_descriptors(st); > 2098: st->cr(); Remove? I think the implementation uses print_cr and you didn't want to add a blank line between this and load average? Also as not all OSs implement it, it will just put space between limits and load average. src/hotspot/os/linux/os_linux.cpp line 5419: > 5417: closedir(dirp); > 5418: if (timed_out) { > 5419: st->print_cr("Open File Descriptors > %d", fds - 1); // minus the opendir fd itself Open File Descriptors: > %d (with the colon like everywhere else?) src/hotspot/os/windows/os_windows.cpp line 6262: > 6260: > 6261: void os::print_open_file_descriptors(outputStream* st) { > 6262: // File descriptor counting not supported on Windows. If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709296759 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709300052 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709305132 From cjplummer at openjdk.org Tue Jan 20 17:31:05 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Jan 2026 17:31:05 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 02:21:38 GMT, SendaoYan wrote: >> Hi all, >> >> This PR make 2 changes which make test more rubustness: >> >> 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. >> 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. >> >> Additional testing: >> >> - [x] All tests touched test by JDK-8373945 with relase build >> - [ ] All tests touched test by JDK-8373945 with fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary runtime.gc() afer classloader has been reclaimed Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3683399494 From dcubed at openjdk.org Tue Jan 20 19:03:17 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 20 Jan 2026 19:03:17 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:56:09 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Fixed whitespace. I last reviewed v19 and I've re-reviewed all the changes since then as one diff between v19 and v25. This looks good to me and I've posted just a couple of comments. src/hotspot/share/runtime/objectMonitor.cpp line 1869: > 1867: > 1868: int ret = OS_OK; > 1869: bool was_notified = true; L2021: // Monitor notify has precedence over thread interrupt. With this change to `was_notified` default value, I don't think we can say that monitor notify has precedence over thread interrupt anymore. src/hotspot/share/runtime/objectMonitor.cpp line 1933: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. > 1933: if (JvmtiExport::should_post_monitor_waited()) { Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3683757507 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709683636 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709638312 From kfarrell at openjdk.org Tue Jan 20 19:51:09 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 19:51:09 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:14:43 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> relocate print out to SYSTEM section and remove AIX impl > > src/hotspot/os/windows/os_windows.cpp line 6262: > >> 6260: >> 6261: void os::print_open_file_descriptors(outputStream* st) { >> 6262: // File descriptor counting not supported on Windows. > > If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. Windows doesn't support UNIX-style file descriptors hence using the word 'supported', I've updated the AIX stub to say 'not implemented' however. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709837631 From kfarrell at openjdk.org Tue Jan 20 19:53:41 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 19:53:41 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v8] In-Reply-To: References: Message-ID: > Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. > > This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: minor updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27971/files - new: https://git.openjdk.org/jdk/pull/27971/files/14ca2e29..926fc920 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=06-07 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971 PR: https://git.openjdk.org/jdk/pull/27971 From bchristi at openjdk.org Tue Jan 20 20:31:18 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:31:18 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29331/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From dcubed at openjdk.org Tue Jan 20 20:34:38 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 20 Jan 2026 20:34:38 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:56:54 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 1869: > >> 1867: >> 1868: int ret = OS_OK; >> 1869: bool was_notified = true; > > L2021: // Monitor notify has precedence over thread interrupt. > > With this change to `was_notified` default value, I don't think we can say > that monitor notify has precedence over thread interrupt anymore. I've tracked that comment back to this very old changeset: $ git log 22929fb78f46^! commit 22929fb78f4606f726b652a25772980336398575 Author: Karen Kinnear Date: Fri Oct 22 15:59:34 2010 -0400 6988353: refactor contended sync subsystem Reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709973474 From bchristi at openjdk.org Tue Jan 20 20:34:55 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:34:55 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29332/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From dholmes at openjdk.org Tue Jan 20 21:02:13 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 21:02:13 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:32:07 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1869: >> >>> 1867: >>> 1868: int ret = OS_OK; >>> 1869: bool was_notified = true; >> >> L2021: // Monitor notify has precedence over thread interrupt. >> >> With this change to `was_notified` default value, I don't think we can say >> that monitor notify has precedence over thread interrupt anymore. > > I've tracked that comment back to this very old changeset: > > > $ git log 22929fb78f46^! > commit 22929fb78f4606f726b652a25772980336398575 > Author: Karen Kinnear > Date: Fri Oct 22 15:59:34 2010 -0400 > > 6988353: refactor contended sync subsystem > > Reduce complexity by factoring synchronizer.cpp > > Reviewed-by: dholmes, never, coleenp I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: 1882 if (interrupted || HAS_PENDING_EXCEPTION) { 1883 was_notified = false; will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710053165 From pchilanomate at openjdk.org Tue Jan 20 21:07:27 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 21:07:27 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:00:01 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread Thanks for the update Serguei, looks good to me. A few comments below. src/hotspot/share/runtime/javaThread.cpp line 1186: > 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { > 1185: // Suspending a vthread transition disabler can cause deadlocks. > 1186: // The HandshakeState::has_operation does not allow such suspends. So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) src/hotspot/share/runtime/javaThread.hpp line 737: > 735: private: > 736: bool _is_in_vthread_transition; // thread is in virtual thread mount state transition > 737: bool _is_vthread_transition_disabler; // thread currently disabled vthread transitions Should we make this field `JVMTI` only? src/hotspot/share/runtime/suspendResumeManager.cpp line 136: > 134: while (is_suspended()) { > 135: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_target)); > 136: assert(!_target->is_vthread_transition_disabler(), "attempt to suspend a vthread transition disabler"); We could check this once before the loop since only the current thread changes `_is_vthread_transition_disabler`. test/hotspot/jtreg/ProblemList.txt line 2: > 1: # > 2: # Copyright (c) 2016, 2026, Oracle and/or its affiliates. All rights reserved. Not needed anymore. ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3684247351 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710046216 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710038316 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710050645 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710059988 From kcr at openjdk.org Tue Jan 20 21:34:45 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:34:45 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505 From kcr at openjdk.org Tue Jan 20 21:35:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:35:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038 From prr at openjdk.org Tue Jan 20 22:05:29 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:05:29 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562 From prr at openjdk.org Tue Jan 20 22:08:39 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:08:39 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706 From naoto at openjdk.org Tue Jan 20 22:43:41 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:43:41 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM from i18n point of view. Probably needs more reviews from hotspot side test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > 1: /* > 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. nit: needs to keep 2025 ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3684605144 PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710321875 From duke at openjdk.org Tue Jan 20 23:14:19 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 20 Jan 2026 23:14:19 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v9] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: added support to summarize AOT cache sharing usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/d29848e8..3efe6afc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=07-08 Stats: 38 lines in 4 files changed: 31 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From ysuenaga at openjdk.org Wed Jan 21 01:07:47 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 21 Jan 2026 01:07:47 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year Javadoc says IOException is: > Signals that an I/O exception of some sort has occurred. This class is the general class of exceptions produced by failed or interrupted I/O operations. I think MonitorException and URISyntaxException do not fit this description. Is AttachOperationFailedException more appropriate? Javadoc says as following. > This exception can be thrown by the various operations of [VirtualMachine](https://docs.oracle.com/en/java/javase/25/docs/api/jdk.attach/com/sun/tools/attach/VirtualMachine.html) when the operation fails in the target VM. If there is a communication error, a regular IOException will be thrown. AttachOperationFailedException inherits IOException, and case (2) and (4) can be considered attach operation error, not a communication error. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3775646660 From smarks at openjdk.org Wed Jan 21 01:16:18 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:18 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com> On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489 From smarks at openjdk.org Wed Jan 21 01:16:22 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:22 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880 From bchristi at openjdk.org Wed Jan 21 01:33:46 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2] In-Reply-To: References: Message-ID: > This brings in cpu26_01 changes. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29332/files - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:33:48 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:48 GMT Subject: [jdk26] Integrated: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: 7ac780da Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:34:06 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:06 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2] In-Reply-To: References: Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com> > This brings in cpu26_01 changes. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29331/files - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From bchristi at openjdk.org Wed Jan 21 01:34:09 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:09 GMT Subject: Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: e25a5a48 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206 Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29331 From syan at openjdk.org Wed Jan 21 02:01:30 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 02:01:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3685013389 From cjplummer at openjdk.org Wed Jan 21 02:37:46 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Jan 2026 02:37:46 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29058#pullrequestreview-3685097176 From duke at openjdk.org Wed Jan 21 03:02:33 2026 From: duke at openjdk.org (He-Pin (kerr)) Date: Wed, 21 Jan 2026 03:02:33 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: References: Message-ID: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo wrote: >> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. >> >> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. >> >> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. >> >> ### Summary of implementation >> >> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. >> >> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). >> >> ### Notes >> >> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Add check for SingleStep events > - Merge branch 'master' into JDK-8369238 > - fix to JvmtiHideSingleStepping > - Suggested fix in macroAssembler_ppc.cpp > - Improve comment and assert msg > - More fixes from David's comments > - Merge branch 'master' into JDK-8369238 > - add const to references > - Improve comment in anchor_mark_set_pd > - More comments from Coleen > - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198 Will this be backported to Java 25 LTS? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3775903843 From syan at openjdk.org Wed Jan 21 03:42:06 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:42:06 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> References: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> Message-ID: On Tue, 20 Jan 2026 06:03:00 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary runtime.gc() afer classloader has been reclaimed > > Thanks for addressing all the feedback. Thanks for the suggestions and reviews @lmesnik @plummercj ------------- PR Comment: https://git.openjdk.org/jdk/pull/29285#issuecomment-3775982942 From syan at openjdk.org Wed Jan 21 03:42:07 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:42:07 GMT Subject: Integrated: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: <_t6tz7eMUbF_6aLOYbJdoGzenjLeQmKygr8S5JW1lis=.37cc787e-33cf-44e8-b70a-fbccf6f17419@github.com> On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [x] All tests touched test by JDK-8373945 with relase build > - [x] All tests touched test by JDK-8373945 with fastdebug build This pull request has now been integrated. Changeset: 599ed0bb Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/599ed0bb5fd62e26c71651bc02f198cd27636cfb Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/29285 From pchilanomate at openjdk.org Wed Jan 21 05:05:56 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:05:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:56:09 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Fixed whitespace. Looks good overall, just a few comments. Thanks. src/hotspot/share/runtime/objectMonitor.cpp line 558: > 556: bool is_virtual = ce != nullptr && ce->is_virtual_thread(); > 557: if (is_virtual) { > 558: notify_contended_enter(current, post_jvmti_events); We should also add `post_jvmti_event &&` to L567 below. src/hotspot/share/runtime/objectMonitor.cpp line 2065: > 2063: did_notify = true; > 2064: > 2065: if (!JvmtiExport::should_post_monitor_waited()) { For the vthread case this value could be different from the one read above. src/hotspot/share/runtime/objectMonitor.cpp line 2079: > 2077: iterator->TState = ObjectWaiter::TS_RUN; > 2078: > 2079: OrderAccess::fence(); Is the fence needed? We already synchronize with `_wait_set_lock`. src/hotspot/share/runtime/objectMonitor.cpp line 2085: > 2083: if (!iterator->is_vthread()) { > 2084: iterator->wait_reenter_begin(this); > 2085: if (has_unmounted_vthreads()) { The thread is going to call `enter` for this case so this is not needed. Same with `wait_reenter_begin` above. src/hotspot/share/runtime/objectMonitor.cpp line 2105: > 2103: } > 2104: return did_notify; > 2105: } Given that there are more differences than common code, I think it's probably better to just separate the vthread and platform thread paths to make it easier to read. Something like this: https://github.com/openjdk/jdk/compare/pr/27040...pchilano:jdk:altnotify You could add a comment on top of the method about the behavior when monitor_waited event is enabled. src/hotspot/share/runtime/objectMonitor.cpp line 2291: > 2289: // because, if monitor_waited JVMTI event is allowed, there can be a vthead which > 2290: // is not on the entry_list, but has been notified in the sense that it has been > 2291: // unparked directly in notify_internal(). Its state is then TS_RUN. Suggestion for shorter comment: // We check the state rather than was_notified because, when JVMTI // monitor_waited event is enabled, the notifier only unparks the waiter // without adding it to the entry_list. src/hotspot/share/runtime/objectMonitor.hpp line 367: > 365: bool enter_is_async_deflating(); > 366: void notify_contended_enter(JavaThread *current, bool post_jvmti_events = true); > 367: void post_waited_event(JavaThread* current, EventJavaMonitorWait* wait_event, bool was_notified, ObjectWaiter* node, jlong millis, int ret); Leftover? ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3685329768 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710948914 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710964239 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710957840 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710958952 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710969804 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710956795 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710954338 From pchilanomate at openjdk.org Wed Jan 21 05:05:58 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:05:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:59:57 GMT, David Holmes wrote: >> I've tracked that comment back to this very old changeset: >> >> >> $ git log 22929fb78f46^! >> commit 22929fb78f4606f726b652a25772980336398575 >> Author: Karen Kinnear >> Date: Fri Oct 22 15:59:34 2010 -0400 >> >> 6988353: refactor contended sync subsystem >> >> Reduce complexity by factoring synchronizer.cpp >> >> Reviewed-by: dholmes, never, coleenp > > I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: > > 1882 if (interrupted || HAS_PENDING_EXCEPTION) { > 1883 was_notified = false; > > will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. > > The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. Might be clearer to move `bool was_notified = true;` right before the branch at L1908 where we determine if there was a notification or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710950713 From pchilanomate at openjdk.org Wed Jan 21 05:06:00 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:06:00 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:42:54 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 1933: > >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >> 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. >> 1933: if (JvmtiExport::should_post_monitor_waited()) { > > Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? I think we will have to add it as a branch condition since the event could have been enabled after notification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710952492 From dholmes at openjdk.org Wed Jan 21 05:13:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:13:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> On Tue, 20 Jan 2026 22:38:26 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > >> 1: /* >> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. > > nit: needs to keep 2025 Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710989942 From sspitsyn at openjdk.org Wed Jan 21 05:23:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:23:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:54:46 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread > > src/hotspot/share/runtime/javaThread.hpp line 737: > >> 735: private: >> 736: bool _is_in_vthread_transition; // thread is in virtual thread mount state transition >> 737: bool _is_vthread_transition_disabler; // thread currently disabled vthread transitions > > Should we make this field `JVMTI` only? Good suggestion, thanks! Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711008857 From dholmes at openjdk.org Wed Jan 21 05:25:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:25:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:48:00 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1933: >> >>> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >>> 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. >>> 1933: if (JvmtiExport::should_post_monitor_waited()) { >> >> Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? > > I think we will have to add it as a branch condition since the event could have been enabled after notification. If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2711012799 From dholmes at openjdk.org Wed Jan 21 05:30:45 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:30:45 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:23:14 GMT, David Holmes wrote: >> I think we will have to add it as a branch condition since the event could have been enabled after notification. > > If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). And the notification code would have to assume that the event will be enabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2711019472 From sspitsyn at openjdk.org Wed Jan 21 05:41:58 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:41:58 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:57:29 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread > > src/hotspot/share/runtime/javaThread.cpp line 1186: > >> 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { >> 1185: // Suspending a vthread transition disabler can cause deadlocks. >> 1186: // The HandshakeState::has_operation does not allow such suspends. > > So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) Good check, thanks. The `JvmtiJavaUpcallMark` hides the JVMTI events during the `interrupt` upcall: JvmtiEnv::InterruptThread(jthread thread) { . . . if (java_lang_VirtualThread::is_instance(thread_obj)) { // For virtual threads we have to call into Java to interrupt: Handle obj(current_thread, thread_obj); JvmtiJavaUpcallMark jjum(current_thread); // hide JVMTI events for Java upcall <== !!! JavaValue result(T_VOID); JavaCalls::call_virtual(&result, obj, vmClasses::Thread_klass(), vmSymbols::interrupt_method_name(), vmSymbols::void_method_signature(), current_thread); > src/hotspot/share/runtime/suspendResumeManager.cpp line 136: > >> 134: while (is_suspended()) { >> 135: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_target)); >> 136: assert(!_target->is_vthread_transition_disabler(), "attempt to suspend a vthread transition disabler"); > > We could check this once before the loop since only the current thread changes `_is_vthread_transition_disabler`. Good suggestion, thanks! Fixed now. > test/hotspot/jtreg/ProblemList.txt line 2: > >> 1: # >> 2: # Copyright (c) 2016, 2026, Oracle and/or its affiliates. All rights reserved. > > Not needed anymore. Good catch, thanks. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711037099 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711038426 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711039636 From dholmes at openjdk.org Wed Jan 21 05:46:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:46:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 10:03:15 GMT, Ivan Bereziuk wrote: > Do you think we need to be able changing the timestamp format (say "-T=UTC")? The main use of the time-stamp is to be able to correlate the time the diagnostic command was run, with the time of other events captured in other logs. So for that you would want compatible/comparable timestamps. As I mentioned previously UL has different timestamp formats, so be able to match those may be of benefit. Though I could also see that as being a future enhancement once we see how the basic wall-clock timestamp is received. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776296670 From sspitsyn at openjdk.org Wed Jan 21 05:55:33 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:55:33 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v14] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: moved vthread_transition_disabler under JVMTI_ONLY; two more tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/05b4c996..64e7dc9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=12-13 Stats: 16 lines in 5 files changed: 3 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From dholmes at openjdk.org Wed Jan 21 06:02:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 06:02:40 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/d32dc5c4...5f1cefe0 > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776344918 From jbhateja at openjdk.org Wed Jan 21 07:04:04 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 21 Jan 2026 07:04:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Fri, 19 Dec 2025 07:01:31 GMT, Emanuel Peter wrote: >> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. >> Hi @eme64 , Kindly share your comments. > > @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) Hi @eme64 , Your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3776496085 From alanb at openjdk.org Wed Jan 21 07:25:57 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 07:25:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: <63zZ3oyXzNCOjLubKLhsa63UwZGSh1-3o-YLX3YbjF0=.2e2ca1cd-a933-4a59-9c5f-bc9806a5ff14@github.com> On Wed, 21 Jan 2026 06:00:18 GMT, David Holmes wrote: > > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. > > That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. For anything new then we should try to use ISO 8601 unless there is a good reason to do otherwise. The "yyyy-MM-dd HH:mm:ss" format, seen in the jstack and jcmd Thread.print output, seems to go back a long way. I wonder how risky it would be change that now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776554080 From sgehwolf at openjdk.org Wed Jan 21 09:07:51 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 09:07:51 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 05:10:15 GMT, David Holmes wrote: >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. >> >> nit: needs to keep 2025 > > Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711604932 From epeter at openjdk.org Wed Jan 21 09:27:09 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:09 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3777034545 From epeter at openjdk.org Wed Jan 21 09:27:12 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:12 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:51:20 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: >> >>> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >>> 67: >>> 68: static void AssertEquals(int actual, int expected) { >> >> There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. > > I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. Can we not do those changes in a separate change, please? It will make it easier to review the rest of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2711675095 From alanb at openjdk.org Wed Jan 21 09:33:44 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 09:33:44 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 01:04:03 GMT, Yasumasa Suenaga wrote: > AttachOperationFailedException inherits IOException, and case (2) and (4) can be considered attach operation error, not a communication error. That would be okay to throw, and would be okay to add a constructor that takes a cause. I think we should remove the new constructor from AttachNotSupportedException, it should not be needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3777069955 From sgehwolf at openjdk.org Wed Jan 21 10:05:30 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Restore Bellsoft copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/9f93451f..e539a64f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Wed Jan 21 10:05:31 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:31 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 09:03:25 GMT, Severin Gehwolf wrote: >> Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. > > OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711832957 From ysuenaga at openjdk.org Wed Jan 21 11:47:07 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 21 Jan 2026 11:47:07 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: <3GIIiStTym3cnj1CDyMn2LASf_j5-r7ZiEwwa1pYZno=.f46f2d7e-d04d-4796-96f5-cb143b92b65e@github.com> On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga wrote: >> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. >> >> >> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep >> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 >> 2025-12-17 06:34:37 >> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000078a8bc13f200, length=10, elements={ >> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, >> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, >> : >> >> >> Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). >> >> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: >> >> >> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug >> / # /usr/lib/jvm/jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> / # ls -l /proc/1/cwd >> ls: /proc/1/cwd: cannot read link: Permission denied >> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd >> >> >> >> After this change, we can see following exception on the console of jcmd when we encounter this situation: >> >> # jcmd 1 VM.version >> 1: >> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process >> at jdk.attac... > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Fix line > - Update copyright year Ok, I will file it to JBS and submit CSR to add new constructor to AttachOperationFailedException. BTW should I withdraw the CSR for AttachNotSupportedException? and can I remove new constructor in AttachNotSupportedException in new ticket? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3777651412 From dholmes at openjdk.org Wed Jan 21 12:19:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 12:19:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 10:00:15 GMT, Severin Gehwolf wrote: >> OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. > > Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > I'm also not an Oracle contributor, fwiw. We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712314104 From sgehwolf at openjdk.org Wed Jan 21 12:53:40 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 12:53:40 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 12:16:17 GMT, David Holmes wrote: >> Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > >> I'm also not an Oracle contributor, fwiw. > > We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712437275 From aartemov at openjdk.org Wed Jan 21 13:26:33 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:33 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: Message-ID: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewers' comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/f672d155..20a81450 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=25-26 Stats: 101 lines in 2 files changed: 23 ins; 60 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Wed Jan 21 13:26:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:46:56 GMT, Patricio Chilano Mateo wrote: >> I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: >> >> 1882 if (interrupted || HAS_PENDING_EXCEPTION) { >> 1883 was_notified = false; >> >> will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. >> >> The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. > > Might be clearer to move `bool was_notified = true;` right before the branch at L1908 where we determine if there was a notification or not. I think we just undo this recent change, moving `bool was_notified = true;` to L1908 is not possible as it is used further at L2012 outside of this huge code block. So it has to be declared where it used to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712552530 From aartemov at openjdk.org Wed Jan 21 13:26:39 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:45:49 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 558: > >> 556: bool is_virtual = ce != nullptr && ce->is_virtual_thread(); >> 557: if (is_virtual) { >> 558: notify_contended_enter(current, post_jvmti_events); > > We should also add `post_jvmti_event &&` to L567 below. Good catch, added! > src/hotspot/share/runtime/objectMonitor.cpp line 2079: > >> 2077: iterator->TState = ObjectWaiter::TS_RUN; >> 2078: >> 2079: OrderAccess::fence(); > > Is the fence needed? We already synchronize with `_wait_set_lock`. Actually it is not, as we are inside of a wider critical section. > src/hotspot/share/runtime/objectMonitor.cpp line 2105: > >> 2103: } >> 2104: return did_notify; >> 2105: } > > Given that there are more differences than common code, I think it's probably better to just separate the vthread and platform thread paths to make it easier to read. Something like this: https://github.com/openjdk/jdk/compare/pr/27040...pchilano:jdk:altnotify > You could add a comment on top of the method about the behavior when monitor_waited event is enabled. Thanks, I have incorporated your changes. > src/hotspot/share/runtime/objectMonitor.cpp line 2291: > >> 2289: // because, if monitor_waited JVMTI event is allowed, there can be a vthead which >> 2290: // is not on the entry_list, but has been notified in the sense that it has been >> 2291: // unparked directly in notify_internal(). Its state is then TS_RUN. > > Suggestion for shorter comment: > > // We check the state rather than was_notified because, when JVMTI > // monitor_waited event is enabled, the notifier only unparks the waiter > // without adding it to the entry_list. Yes, a bit wordy, fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 367: > >> 365: bool enter_is_async_deflating(); >> 366: void notify_contended_enter(JavaThread *current, bool post_jvmti_events = true); >> 367: void post_waited_event(JavaThread* current, EventJavaMonitorWait* wait_event, bool was_notified, ObjectWaiter* node, jlong millis, int ret); > > Leftover? Yes, a leftover from a previous iteration, thanks for spotting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553017 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712554279 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712557326 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553670 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553472 From aartemov at openjdk.org Wed Jan 21 13:26:41 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:26:38 GMT, David Holmes wrote: >> If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). > > And the notification code would have to assume that the event will be enabled. I added it back to the branch condition and modified the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712551707 From kevinw at openjdk.org Wed Jan 21 15:26:35 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:26:35 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/1e69e598...5f1cefe0 OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3778803463 From kevinw at openjdk.org Wed Jan 21 15:30:14 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:30:14 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: <4K9-nveG7r0_S8x5ebJdAruuq6dCWa_VWDInEPn-36w=.b4cbb9e7-fe62-4156-953b-478b0f927d15@github.com> On Tue, 20 Jan 2026 19:47:24 GMT, Kieran Farrell wrote: >> src/hotspot/os/windows/os_windows.cpp line 6262: >> >>> 6260: >>> 6261: void os::print_open_file_descriptors(outputStream* st) { >>> 6262: // File descriptor counting not supported on Windows. >> >> If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. > > Windows doesn't support UNIX-style file descriptors hence using the word 'supported', I've updated the AIX stub to say 'not implemented' however. ah yes thanks. Not heard of a suggestion of printing a Windows HANDLE count so far. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2713088966 From kevinw at openjdk.org Wed Jan 21 15:39:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:39:39 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v8] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell wrote: >> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. >> >> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > minor updates Looks good I think. We should update issue title and PR title to remove mention of maximum limit. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27971#pullrequestreview-3687902195 From duke at openjdk.org Wed Jan 21 16:28:15 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:28:15 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v3] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision: - improve test. Assert new ISO 8601 format - handle timestamp in parse_and_execute(). Thread.print is exceptional. Add default initialation to JcmdOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/5f1cefe0..c702901d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01-02 Stats: 133 lines in 4 files changed: 19 ins; 101 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From shade at openjdk.org Wed Jan 21 16:47:43 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:47:43 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: > Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. > > Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. > > Shenandoah added a few asserts to catch these errors: > SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) > > ...but G1 would also benefit from the similar safety mechanism. > > This PR strengthens the code to prevent future accidents. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc` > - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z > - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z > - [x] GHA, cross-compilation only Aleksey Shipilev 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: Some polishing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28703/files - new: https://git.openjdk.org/jdk/pull/28703/files/5c2206b9..db78bed3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=03-04 Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28703.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28703/head:pull/28703 PR: https://git.openjdk.org/jdk/pull/28703 From duke at openjdk.org Wed Jan 21 16:54:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:54:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 15:24:15 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/e81dffc4...5f1cefe0 > > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: > Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? > (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... > This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. > It sidesteps the problem that Thread.print uses an arguably "wrong" format. > (An in time, maybe Thread.print would migrate to not printing a timestamp.) > > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. > Heap dumping prints its own time taken, but few other commands consider it interesting.) @kevinjwalls > not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Yes. That is indeed an option to consider. In here * I've removed "print timestamp" handling from `DCmd::execute()`. Now it's handled in `DCmd::Executor::parse_and_execute()`. The additional parameter passed to `DCmd::execute` serves the only purpose - let `Thread.print` dcmd be backwards compatible and print a "timestamp" of old format when "-T" flag was passed. * I have also embraced an ISO 8601 format. Example `2026-01-21T16:58:49.518+0100`; Alan, David, thank you. It might be fine to keep framework of "common jcmd flags" in place. Executors would need to know about "-format=json" if that becomes a common flag in the future. Other than that, it might be fine to let "Thread.print" print two timestamps which will make the implementation simpler: https://github.com/openjdk/jdk/pull/29325 Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3779616328 From shade at openjdk.org Wed Jan 21 17:35:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 17:35:58 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> References: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> Message-ID: On Wed, 21 Jan 2026 13:28:39 GMT, Thomas Schatzl wrote: > Looks good apart from minor nits (extra spaces). Sorry for taking so long. No problem, thanks for looking! This is not urgent, one of those "safety in depth" fixes, really. Refixed the PR after borked merge. Re-ran `hotspot_gc` without issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3779958493 From pchilanomate at openjdk.org Wed Jan 21 18:18:53 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 18:18:53 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:36:32 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1186: >> >>> 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { >>> 1185: // Suspending a vthread transition disabler can cause deadlocks. >>> 1186: // The HandshakeState::has_operation does not allow such suspends. >> >> So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) > > Good check, thanks. > The `JvmtiJavaUpcallMark` hides the JVMTI events during the `interrupt` upcall: > > JvmtiEnv::InterruptThread(jthread thread) { > . . . > if (java_lang_VirtualThread::is_instance(thread_obj)) { > // For virtual threads we have to call into Java to interrupt: > Handle obj(current_thread, thread_obj); > JvmtiJavaUpcallMark jjum(current_thread); // hide JVMTI events for Java upcall <== !!! > JavaValue result(T_VOID); > JavaCalls::call_virtual(&result, > obj, > vmClasses::Thread_klass(), > vmSymbols::interrupt_method_name(), > vmSymbols::void_method_signature(), > current_thread); I see, could we keep the original assert? Should not be possible to request suspend on a transition disabler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2713776399 From duke at openjdk.org Wed Jan 21 18:48:45 2026 From: duke at openjdk.org (Larry Cable) Date: Wed, 21 Jan 2026 18:48:45 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: fixed initialization bug in AOT cache sharing summary code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/3efe6afc..341643a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From sspitsyn at openjdk.org Wed Jan 21 19:48:27 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 19:48:27 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:13:39 GMT, Patricio Chilano Mateo wrote: > I see, could we keep the original assert? Should not be possible to request suspend on a transition disabler. Even though such a request is not possible, it should be allowed in general as it does not break anything at this execution point. :) But I do not see a problem to restore the assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714084109 From sspitsyn at openjdk.org Wed Jan 21 20:11:53 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 20:11:53 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: restored the original assert with a different message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/64e7dc9e..bb0fc064 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=13-14 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From pchilanomate at openjdk.org Wed Jan 21 20:16:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 20:16:24 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: <3QgrFiiQHK2BxQb36Za5uucbGcl5lbjgwHloH1D7rmo=.8adaeb7c-00c8-4459-84c2-ba1cb66f841f@github.com> On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Thanks Serguei, looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689199704 From pchilanomate at openjdk.org Wed Jan 21 20:39:55 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 20:39:55 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. Thanks for the updates, looks good to me. src/hotspot/share/runtime/objectMonitor.hpp line 42: > 40: class BasicLock; > 41: class ContinuationWrapper; > 42: class EventJavaMonitorWait; Nit: leftover ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3689302980 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2714253300 From lmesnik at openjdk.org Wed Jan 21 21:51:14 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 Jan 2026 21:51:14 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Looks good. A couple of small nits, feel free to ignore them. src/hotspot/share/runtime/handshake.cpp line 525: > 523: #if INCLUDE_JVMTI > 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { > 525: // filter out suspend operations while JavaThread is in disable_suspend mode does it makes sense to update comment to // filter out suspend operations while JavaThread is in disable_suspend mode or in transition or something more generic // check if JavaThread can be suspended in this handshake test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp line 63: > 61: JNIEXPORT void JNICALL > 62: Java_ThreadStateTest2_setMonitorContendedMode(JNIEnv* jni, jclass klass, jboolean enable) { > 63: jvmtiError err = jvmti->SetEventNotificationMode(enable ? JVMTI_ENABLE : JVMTI_DISABLE, JVMTI_EVENT_MONITOR_CONTENDED_ENTER, nullptr); You can use set_event_notification_mode(jvmtiEnv*, ... ) from jvmti_common.h ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689496071 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714417725 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714441116 From sspitsyn at openjdk.org Wed Jan 21 21:59:38 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 21:59:38 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Patricio and Leonid, thank you a lot for reviews and suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3781344905 From sspitsyn at openjdk.org Wed Jan 21 23:46:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 23:46:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v16] In-Reply-To: References: Message-ID: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: minor comment tweak in a comment; use test lib function set_event_notification_mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/bb0fc064..b68dbe45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=14-15 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From lmesnik at openjdk.org Wed Jan 21 23:46:40 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 Jan 2026 23:46:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v16] In-Reply-To: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> References: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> Message-ID: On Wed, 21 Jan 2026 23:43:07 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: minor comment tweak in a comment; use test lib function set_event_notification_mode Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689851937 From sspitsyn at openjdk.org Wed Jan 21 23:46:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 23:46:45 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 21:33:30 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: restored the original assert with a different message > > src/hotspot/share/runtime/handshake.cpp line 525: > >> 523: #if INCLUDE_JVMTI >> 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { >> 525: // filter out suspend operations while JavaThread is in disable_suspend mode > > does it makes sense to update comment to > // filter out suspend operations while JavaThread is in disable_suspend mode or in transition > or something more generic > // check if JavaThread can be suspended in this handshake Thanks. How about more generic? : @@ -522,7 +522,7 @@ HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool che assert(allow_suspend || !check_async_exception, "invalid case"); #if INCLUDE_JVMTI if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { - // filter out suspend operations while JavaThread is in disable_suspend mode + // filter out suspend operations while JavaThread can not be suspended allow_suspend = false; } #endif > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp line 63: > >> 61: JNIEXPORT void JNICALL >> 62: Java_ThreadStateTest2_setMonitorContendedMode(JNIEnv* jni, jclass klass, jboolean enable) { >> 63: jvmtiError err = jvmti->SetEventNotificationMode(enable ? JVMTI_ENABLE : JVMTI_DISABLE, JVMTI_EVENT_MONITOR_CONTENDED_ENTER, nullptr); > > You can use > set_event_notification_mode(jvmtiEnv*, ... ) > from jvmti_common.h Thanks, fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714723247 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714723634 From pchilanomate at openjdk.org Thu Jan 22 01:17:28 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 01:17:28 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> References: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> Message-ID: On Wed, 21 Jan 2026 02:58:33 GMT, He-Pin(kerr) wrote: > Will this be backported to Java 25 LTS? > No plans to backport it. Feel free to follow up on the loom-dev mailing list instead (see https://mail.openjdk.org/pipermail/loom-dev/2025-November/008039.html). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3781955460 From dholmes at openjdk.org Thu Jan 22 01:51:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 01:51:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 16:51:17 GMT, Ivan Bereziuk wrote: > Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? Lowercase `-t` seems more consistent with other options ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3782041944 From sspitsyn at openjdk.org Thu Jan 22 01:57:08 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Jan 2026 01:57:08 GMT Subject: Integrated: 8373366: HandshakeState should disallow suspend ops for disabler threads In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:18:11 GMT, Serguei Spitsyn wrote: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 This pull request has now been integrated. Changeset: 3d919ad4 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/3d919ad43a041eb60ce51e78831c77fd3b109aee Stats: 290 lines in 7 files changed: 270 ins; 4 del; 16 mod 8373366: HandshakeState should disallow suspend ops for disabler threads 8375362: Deadlock with unmount of suspended virtual thread interrupting another virtual thread Reviewed-by: lmesnik, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/28740 From dholmes at openjdk.org Thu Jan 22 02:30:02 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 02:30:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. There are still issues with `was_notified` and I don't think the possibility of the event enabling changing has been fully handled. src/hotspot/share/runtime/objectMonitor.cpp line 1907: > 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. > 1906: // That is, we fail toward safety. > 1907: was_notified = true; You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" src/hotspot/share/runtime/objectMonitor.cpp line 2066: > 2064: } > 2065: } else { > 2066: if (!JvmtiExport::should_post_monitor_waited()) { What if this has changed value since we checked it above? ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3690267548 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715060072 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715066067 From dholmes at openjdk.org Thu Jan 22 02:40:59 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 02:40:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> On Thu, 22 Jan 2026 02:21:11 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1907: > >> 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. >> 1906: // That is, we fail toward safety. >> 1907: was_notified = true; > > You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" This should be: was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; and no need to adjust to false below (as it will already be false). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715087288 From ysuenaga at openjdk.org Thu Jan 22 02:53:06 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 02:53:06 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 09:30:48 GMT, Alan Bateman wrote: >> Javadoc says IOException is: >>> Signals that an I/O exception of some sort has occurred. This class is the general class of exceptions produced by failed or interrupted I/O operations. >> >> I think MonitorException and URISyntaxException do not fit this description. >> >> Is AttachOperationFailedException more appropriate? Javadoc says as following. >>> This exception can be thrown by the various operations of [VirtualMachine](https://docs.oracle.com/en/java/javase/25/docs/api/jdk.attach/com/sun/tools/attach/VirtualMachine.html) when the operation fails in the target VM. If there is a communication error, a regular IOException will be thrown. >> >> AttachOperationFailedException inherits IOException, and case (2) and (4) can be considered attach operation error, not a communication error. > >> AttachOperationFailedException inherits IOException, and case (2) and (4) can be considered attach operation error, not a communication error. > > That would be okay to throw, and would be okay to add a constructor that takes a cause. > > I think we should remove the new constructor from AttachNotSupportedException, it should not be needed. @AlanBateman I filed it and submit CSR on JBS, and sent PR as #29355. Let's keep discuss on it, and I hope you review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3782224956 From ysuenaga at openjdk.org Thu Jan 22 02:58:59 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 02:58:59 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() Message-ID: [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. ------------- Commit messages: - Remove AttachNotSupportedException constructor with the cause - Use AttachOperationFailedException instead of AttachNotSupportedException in findTargetProcessTmpDirectory - IOE when attaching shouldn't be wrapped with AttachNotSupportedException Changes: https://git.openjdk.org/jdk/pull/29355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376052 Stats: 41 lines in 3 files changed: 17 ins; 16 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29355/head:pull/29355 PR: https://git.openjdk.org/jdk/pull/29355 From pchilanomate at openjdk.org Thu Jan 22 03:38:40 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 03:38:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 02:37:41 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1907: >> >>> 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. >>> 1906: // That is, we fail toward safety. >>> 1907: was_notified = true; >> >> You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" > > This should be: > > was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; > > and no need to adjust to false below (as it will already be false). Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715178509 From dholmes at openjdk.org Thu Jan 22 04:22:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:22:36 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1916: > 1914: } > 1915: } > 1916: // The thread is now either on off-list (TS_RUN), Suggestion: // The thread is now either off-list (TS_RUN), Pre-existing typo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715241999 From dholmes at openjdk.org Thu Jan 22 04:36:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:36:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1933: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > 1932: // An event could have been enabled after notification, need to check the state. > 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: if (JvmtiExport::should_post_monitor_waited()) { if (node.TState != ObjectWaiter::TS_ENTER) { // Process suspend requests now if any, before posting the event. ThreadBlockInVM tbvm(current, true); } JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715266992 From dholmes at openjdk.org Thu Jan 22 04:56:10 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:56:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 03:35:10 GMT, Patricio Chilano Mateo wrote: >> This should be: >> >> was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; >> >> and no need to adjust to false below (as it will already be false). > > Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715292501 From dholmes at openjdk.org Thu Jan 22 04:56:10 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:56:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 04:50:05 GMT, David Holmes wrote: >> Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). > > Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. Though it would be clearer to just have: 1869 bool was_notified = true; and delete line 1907. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715297305 From dholmes at openjdk.org Thu Jan 22 05:02:02 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:02:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 04:34:05 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1933: > >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >> 1932: // An event could have been enabled after notification, need to check the state. >> 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > > I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: > > if (JvmtiExport::should_post_monitor_waited()) { > if (node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event. > ThreadBlockInVM tbvm(current, true); > } > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715307376 From dholmes at openjdk.org Thu Jan 22 05:21:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:21:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 02:24:39 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 2066: > >> 2064: } >> 2065: } else { >> 2066: if (!JvmtiExport::should_post_monitor_waited()) { > > What if this has changed value since we checked it above? Sorry ignore that - got the block structure wrong again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715338855 From dholmes at openjdk.org Thu Jan 22 05:37:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:37:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1931: > 1929: // (Don't cache naked oops over safepoints, of course). > 1930: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. Pre-existing but I just noticed this. We should only be posting events in the "interruptible" case. Refer above: 1824 if (interruptible && JvmtiExport::should_post_monitor_wait()) { 1825 JvmtiExport::post_monitor_wait(current, object(), millis); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715368280 From ysuenaga at openjdk.org Thu Jan 22 06:40:06 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 06:40:06 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: > [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. > > In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29355/files - new: https://git.openjdk.org/jdk/pull/29355/files/dc4825db..c9051cde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29355&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29355&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29355/head:pull/29355 PR: https://git.openjdk.org/jdk/pull/29355 From alanb at openjdk.org Thu Jan 22 07:30:04 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jan 2026 07:30:04 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:40:06 GMT, Yasumasa Suenaga wrote: >> [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. >> >> In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 301: > 299: } catch (MonitorException | URISyntaxException e) { > 300: // Other exceptions (happened at MonitoredHost) would be wrapped with AttachOperationFailedException > 301: throw new AttachOperationFailedException("Unable to find target proces", e); Would it be possible to paste in some examples of the cause? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2715649466 From ysuenaga at openjdk.org Thu Jan 22 08:20:08 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 08:20:08 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 07:27:01 GMT, Alan Bateman wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 301: > >> 299: } catch (MonitorException | URISyntaxException e) { >> 300: // Other exceptions (happened at MonitoredHost) would be wrapped with AttachOperationFailedException >> 301: throw new AttachOperationFailedException("Unable to find target proces", e); > > Would it be possible to paste in some examples of the cause? We would not see these exceptions TBH - they are just checked exceptions on `getMonitoredHost()` and `activeVms()`. `sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider` would be instanciated by default when we pass `//localhost` to `getMonitoredHost()`. Both c'tor of `MonitoredHostProvider` and `activeVms()` do not have any `throws` clause. And also `MonitoredHostLocalService` which is loaded by ServiceLoader would not throw any exceptions. `URISyntaxException` comes from `URI` members, but it would not happen because `//localhost` is hard coded, and I believe it does not happen any exceptions on `URI`. The class inherits `MonitoredHost` might be instantiated by user-defined provider class of course, so these checked exceptions should be reported as the cause. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2715792198 From ysuenaga at openjdk.org Thu Jan 22 08:43:56 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 08:43:56 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack PING: Can I get second reviewer? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3783204846 From ysuenaga at openjdk.org Thu Jan 22 08:43:55 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 08:43:55 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v7] In-Reply-To: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> References: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> Message-ID: On Wed, 14 Jan 2026 06:06:28 GMT, Yasumasa Suenaga wrote: >> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update TestJhsdbJstackMixed.java PING: Can I get second reviewer? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29019#issuecomment-3783204222 From sspitsyn at openjdk.org Thu Jan 22 09:14:07 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Jan 2026 09:14:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 04:52:53 GMT, David Holmes wrote: >> Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. > > Though it would be clearer to just have: > > 1869 bool was_notified = true; > > and delete line 1907. Wanted to suggest the same. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715989355 From aartemov at openjdk.org Thu Jan 22 10:44:08 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:08 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v28] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/20a81450..72b583ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=26-27 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Thu Jan 22 10:44:09 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:09 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 09:10:50 GMT, Serguei Spitsyn wrote: >> Though it would be clearer to just have: >> >> 1869 bool was_notified = true; >> >> and delete line 1907. > > Wanted to suggest the same. :) Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314580 From aartemov at openjdk.org Thu Jan 22 10:44:13 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:13 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> Message-ID: On Thu, 22 Jan 2026 04:19:16 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1916: > >> 1914: } >> 1915: } >> 1916: // The thread is now either on off-list (TS_RUN), > > Suggestion: > > // The thread is now either off-list (TS_RUN), > > Pre-existing typo Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 1931: > >> 1929: // (Don't cache naked oops over safepoints, of course). >> 1930: >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > > Pre-existing but I just noticed this. We should only be posting events in the "interruptible" case. Refer above: > > 1824 if (interruptible && JvmtiExport::should_post_monitor_wait()) { > 1825 JvmtiExport::post_monitor_wait(current, object(), millis); Added as an extra condition, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314378 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716312228 From aartemov at openjdk.org Thu Jan 22 10:44:16 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:16 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 04:59:04 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1933: >> >>> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >>> 1932: // An event could have been enabled after notification, need to check the state. >>> 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { >> >> I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: >> >> if (JvmtiExport::should_post_monitor_waited()) { >> if (node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> ThreadBlockInVM tbvm(current, true); >> } >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. I added the changes you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314002 From aartemov at openjdk.org Thu Jan 22 11:00:02 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 11:00:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 20:36:32 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.hpp line 42: > >> 40: class BasicLock; >> 41: class ContinuationWrapper; >> 42: class EventJavaMonitorWait; > > Nit: leftover Removed, thanks for spotting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716392207 From aartemov at openjdk.org Thu Jan 22 10:59:59 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:59:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v29] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/72b583ab..3dff4f17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=27-28 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Thu Jan 22 11:08:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 11:08:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v30] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Fixed whitespaces. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/3dff4f17..eb5afa25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=28-29 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From duke at openjdk.org Thu Jan 22 11:11:04 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 22 Jan 2026 11:11:04 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: Message-ID: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: change flag name from -T to -t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/c702901d..f0e39a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02-03 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From duke at openjdk.org Thu Jan 22 11:28:29 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 22 Jan 2026 11:28:29 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": > > jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename > ^^^^ > > > This is a simplified approach to handle timestamp (v1 is [here](https://github.com/openjdk/jdk/pull/27368)) > > Some diagnostic commands already provide timestamps information. For example `Thread.print` already starts with a timestamp of "yyyy-MM-dd HH:mm:ss" format. > In that case the timestamp is printed twice if "-t" flag is passed to `Thread.print`. > > The time format for the generic timestamp is ISO 8601. Example: `2026-01-21T16:58:49.518+0100` Ivan Bereziuk has updated the pull request incrementally with three additional commits since the last revision: - change timestamp format to ISO 8601 - lowercase flag - improve test. Assert new ISO 8601 format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29325/files - new: https://git.openjdk.org/jdk/pull/29325/files/eaea764d..1047677b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=00-01 Stats: 21 lines in 6 files changed: 1 ins; 5 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29325/head:pull/29325 PR: https://git.openjdk.org/jdk/pull/29325 From kevinw at openjdk.org Thu Jan 22 11:33:25 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 22 Jan 2026 11:33:25 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack (sorry about delay) Just to discuss an alternative: When LinuxAMD64CFrame.sender() finds nextPC, it could recognise the signal handler trampoline, by looking at the return address nextPC and checking if it points to the bytes of the trampoline: 0x7f5e5e094610 <__restore_rt>: 0x48 0xc7 0xc0 0x0f 0x00 0x00 0x00 0x0f (which look as stable as everything else we are relying on here) Then the new frame is created with boolean isSigTrampoline set as a member in LinuxAMD64CFrame. That avoids needing the symbol lookup to decide if it's a trampoline. Then in LinuxAMD64CFrame: closestSymbolToPC() would return the special string if isSigTrampoline without a lookup. isValidFrame would use the isSigTrampoline member, no new parameter needed. getNextCFA would not need to check if it's a trampoline and pass a value to isValidFrame. sender() would not need the symbol lookup, it has the member boolean. Does that make it simpler overall? It would avoid using the symbol name to know if this is a signal handler trampoline, and having special meaning of "" in both places. ------------- PR Review: https://git.openjdk.org/jdk/pull/29023#pullrequestreview-3691996749 From alanb at openjdk.org Thu Jan 22 12:12:23 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jan 2026 12:12:23 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: <0653pVD4jsN8giX-aMprqCvw8Wth2tSSmKzV2wdFrNE=.fe750a26-3381-4f1b-a2eb-e4c1b07b10d1@github.com> On Thu, 22 Jan 2026 08:17:50 GMT, Yasumasa Suenaga wrote: >> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 301: >> >>> 299: } catch (MonitorException | URISyntaxException e) { >>> 300: // Other exceptions (happened at MonitoredHost) would be wrapped with AttachOperationFailedException >>> 301: throw new AttachOperationFailedException("Unable to find target proces", e); >> >> Would it be possible to paste in some examples of the cause? > > We would not see these exceptions TBH - they are just checked exceptions on `getMonitoredHost()` and `activeVms()`. > > `sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider` would be instanciated by default when we pass `//localhost` to `getMonitoredHost()`. Both c'tor of `MonitoredHostProvider` and `activeVms()` do not have any `throws` clause. And also `MonitoredHostLocalService` which is loaded by ServiceLoader would not throw any exceptions. > > `URISyntaxException` comes from `URI` members, but it would not happen because `//localhost` is hard coded, and I believe it does not happen any exceptions on `URI`. > > The class inherits `MonitoredHost` might be instantiated by user-defined provider class of course, so these checked exceptions should be reported as the cause. Can you please provide an example where IOException is thrown? The code in the catch block to use MonitoredHost.getMonitoredHost is surprising (the only dependency on jvmstat should be in the enumerate/list implementation). If URISyntaxException is not possible then it would be okay to throw an AssertionError or InternalError here. It would be useful to get an example or two of when MonitorException is thrown. That seems a reason candidate to wrap in an AttachOperationFailedException but I think have a specific example or two would help the discussion. It would be good to re-flow the comment in findTargetProcessTmpDirectory to reduce the wildly long lines. Right now it is really hard to look at the changes side-by-side. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2716641283 From tschatzl at openjdk.org Thu Jan 22 12:12:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 12:12:26 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev wrote: >> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. >> >> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. >> >> Shenandoah added a few asserts to catch these errors: >> SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) >> >> ...but G1 would also benefit from the similar safety mechanism. >> >> This PR strengthens the code to prevent future accidents. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc` >> - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] GHA, cross-compilation only > > Aleksey Shipilev 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: > > Some polishing Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3692138599 From kevinw at openjdk.org Thu Jan 22 12:36:02 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 22 Jan 2026 12:36:02 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t I am liking the much simpler alternative. I think you did a lot of exploratory work here, but there is a lot of complexity needed just because Thread.print already prints a timestamp. I do not find this ugly or unparseable: $ jcmd -t 2970459 Thread.print 2970459: 2026-01-22T12:05:50.518+0100 2026-01-22 12:05:55 Full thread dump Java HotSpot(TM) 64-Bit Server VM (27-internal-kwalls.open mixed mode, sharing) JDK version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-kwalls.open) Threads class SMR info: ... It would not seem right to add the common flags infrastructure in dcmd framework just in case it's useful in future, just add what we need right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3784154369 From sgehwolf at openjdk.org Thu Jan 22 13:30:58 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:30:58 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. 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 four additional commits since the last revision: - Merge branch 'master' into jdk-8375692-container-test-assert - Restore Bellsoft copyright - Update copyright year - 8375692: Hotspot container tests assert with non-ascii vendor name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/e539a64f..dbe943dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02-03 Stats: 14011 lines in 386 files changed: 8639 ins; 2067 del; 3305 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Thu Jan 22 13:31:01 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:31:01 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Wed, 21 Jan 2026 10:05:30 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Restore Bellsoft copyright @dholmes-ora Any more thoughts on this? OK as it is? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3784411173 From ysuenaga at openjdk.org Thu Jan 22 13:49:50 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 13:49:50 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: <0653pVD4jsN8giX-aMprqCvw8Wth2tSSmKzV2wdFrNE=.fe750a26-3381-4f1b-a2eb-e4c1b07b10d1@github.com> References: <0653pVD4jsN8giX-aMprqCvw8Wth2tSSmKzV2wdFrNE=.fe750a26-3381-4f1b-a2eb-e4c1b07b10d1@github.com> Message-ID: On Thu, 22 Jan 2026 12:09:28 GMT, Alan Bateman wrote: > Can you please provide an example where IOException is thrown? I could not produce IOException, but it might occur if filesystem is broken. AccessDeniedException would happen as following. We can see it easy on attach to rootless container. # ./jcmd 1 VM.version 1: java.nio.file.AccessDeniedException: /proc/1/root/tmp at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113) at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391) at java.base/java.nio.file.Files.isSameFile(Files.java:1418) at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:280) at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:236) at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:87) at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > It would be useful to get an example or two of when MonitorException is thrown. As I said before, I cannot find out the location to throw MonitorException in JDK source around attach mechanism, but it might happen if the user uses custom attach provider. Anyway it is checked exception, so it shouldn't ignore or raise assertion error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2716993417 From cjplummer at openjdk.org Thu Jan 22 16:05:26 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Jan 2026 16:05:26 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v7] In-Reply-To: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> References: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> Message-ID: On Wed, 14 Jan 2026 06:06:28 GMT, Yasumasa Suenaga wrote: >> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update TestJhsdbJstackMixed.java src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java line 88: > 86: .filter(jt -> thread.equals(jt.getThreadProxy())) > 87: .findFirst() > 88: .orElse(null); I wonder if this code should be moved into its own API. Call it something like mapThreadProxyToJavaThread(), or maybe getJavaThreadForThreadProxy(). It would make the code more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2715062051 From shade at openjdk.org Thu Jan 22 16:50:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:50:58 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev wrote: >> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. >> >> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. >> >> Shenandoah added a few asserts to catch these errors: >> SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) >> >> ...but G1 would also benefit from the similar safety mechanism. >> >> This PR strengthens the code to prevent future accidents. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc` >> - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] GHA, cross-compilation only > > Aleksey Shipilev 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: > > Some polishing Thanks! The only GHA failure is due to (the absence of): https://github.com/openjdk/jdk/pull/29254. Looking for a second Reviewer! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3785460384 From pchilanomate at openjdk.org Thu Jan 22 18:38:48 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 18:38:48 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 10:39:23 GMT, Anton Artemov wrote: >> Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. > > Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. > > I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. > > I added the changes you suggested. My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2718123607 From ysuenaga at openjdk.org Fri Jan 23 02:09:30 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 02:09:30 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/aa2ee284..d1864610 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=03-04 Stats: 62 lines in 4 files changed: 24 ins; 26 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Fri Jan 23 02:24:32 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 02:24:32 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:30:34 GMT, Kevin Walls wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler >> - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler >> - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler >> - Fix >> - 8374482: SA does not handle signal handler frame in mixed jstack > > (sorry about delay) > Just to discuss an alternative: > > When LinuxAMD64CFrame.sender() finds nextPC, it could recognise the signal handler trampoline, > by looking at the return address nextPC and checking if it points to the bytes of the trampoline: > 0x7f5e5e094610 <__restore_rt>: 0x48 0xc7 0xc0 0x0f 0x00 0x00 0x00 0x0f > (which look as stable as everything else we are relying on here) > > Then the new frame is created with boolean isSigTrampoline set as a member in LinuxAMD64CFrame. > > That avoids needing the symbol lookup to decide if it's a trampoline. > Then in LinuxAMD64CFrame: > closestSymbolToPC() would return the special string if isSigTrampoline without a lookup. > isValidFrame would use the isSigTrampoline member, no new parameter needed. > getNextCFA would not need to check if it's a trampoline and pass a value to isValidFrame. > sender() would not need the symbol lookup, it has the member boolean. > > Does that make it simpler overall? > > It would avoid using the symbol name to know if this is a signal handler trampoline, and having special meaning of "" in both places. @kevinjwalls Thanks for your comment! It sounds good. I updated PR. > When LinuxAMD64CFrame.sender() finds nextPC, it could recognise the signal handler trampoline, by looking at the return address nextPC and checking if it points to the bytes of the trampoline: 0x7f5e5e094610 <__restore_rt>: 0x48 0xc7 0xc0 0x0f 0x00 0x00 0x00 0x0f (which look as stable as everything else we are relying on here) I guess bytes of `__restore_rt` what you show is the contents of RIP like `x/8xb $rip` in GDB. If so, it is for AMD64 only at least, and it might be different depending on compiler/compiler options for glibc. Thus I added list of signal trampoline in `LinuxDebugger` (for AMD64 only for now). We can add if need for other architectures (AArch64 is different (`__kernel_rt_sigreturn`) at least AFAIK). It is used to detect signal trampoline in `LinuxDebuggerLocal::isSignalTrampoline`. `closestSymbolToPC()` returns `` if the PC is in signal trampoline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3787822614 From ysuenaga at openjdk.org Fri Jan 23 03:06:28 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 03:06:28 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v7] In-Reply-To: References: <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com> Message-ID: On Thu, 22 Jan 2026 02:22:23 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestJhsdbJstackMixed.java > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java line 88: > >> 86: .filter(jt -> thread.equals(jt.getThreadProxy())) >> 87: .findFirst() >> 88: .orElse(null); > > I wonder if this code should be moved into its own API. Call it something like mapThreadProxyToJavaThread(), or maybe getJavaThreadForThreadProxy(). It would make the code more readable. Thanks for your comment. I extracted this logic as `mapThreadProxyToJavaThread()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2719408169 From ysuenaga at openjdk.org Fri Jan 23 03:06:27 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 03:06:27 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v8] In-Reply-To: References: Message-ID: <3N5B8NlV17gaWQIOfbZpzkRxDIwUUZALIxr-hv1L-v0=.b9838ea3-3106-48b2-9889-87acb667c4d0@github.com> > When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: > > > ----------------- 4 ----------------- > "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] > java.lang.Thread.State: TIMED_WAITING (sleeping) > JavaThread state: _thread_blocked > 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 > ----------------- 5 ----------------- > > > This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). > We cannot depend on base pointer to unwind call frames, but SA do that. > > This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. > > However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. > > This change passed serviceability/sa tests on Windows 11. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Extract the owner thread retrieval function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29019/files - new: https://git.openjdk.org/jdk/pull/29019/files/8568a8fb..645b7711 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29019&range=06-07 Stats: 20 lines in 1 file changed: 13 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29019/head:pull/29019 PR: https://git.openjdk.org/jdk/pull/29019 From cjplummer at openjdk.org Fri Jan 23 03:31:13 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Jan 2026 03:31:13 GMT Subject: RFR: 8374469: Mixed jstack does not work on Windows [v8] In-Reply-To: <3N5B8NlV17gaWQIOfbZpzkRxDIwUUZALIxr-hv1L-v0=.b9838ea3-3106-48b2-9889-87acb667c4d0@github.com> References: <3N5B8NlV17gaWQIOfbZpzkRxDIwUUZALIxr-hv1L-v0=.b9838ea3-3106-48b2-9889-87acb667c4d0@github.com> Message-ID: On Fri, 23 Jan 2026 03:06:27 GMT, Yasumasa Suenaga wrote: >> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Extract the owner thread retrieval function Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29019#pullrequestreview-3695519816 From cjplummer at openjdk.org Fri Jan 23 03:34:50 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Jan 2026 03:34:50 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped In-Reply-To: References: Message-ID: <0eaIxJQxBdgGv6-2cx9wP4XR2t1WLyzkQPzytjJAeVw=.ca36ab0c-40d9-4050-b6ae-e9a3c9ca4b7f@github.com> On Sat, 17 Jan 2026 03:49:17 GMT, Chris Plummer wrote: > The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: > > > if (core_pattern[0] == '|') { > written = jio_snprintf(buffer, bufferSize, > - ""%s" (or dumping to %s/core.%d)", > + ""%s" (alternatively, falling back to %s/core.%d)", > &core_pattern[1], p, current_process_id()); > > > CoreUtils was checking for "or ", but it needs to check for "alternatively...". > > Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. Ping! Could I get a second review please. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3787999438 From jbhateja at openjdk.org Fri Jan 23 04:24:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 04:24:57 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/fe7075ee..72d15568 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=12-13 Stats: 1415 lines in 52 files changed: 441 ins; 259 del; 715 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Fri Jan 23 05:01:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 05:01:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed > @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) Hi @eme64 , I have done some cleanups, following is the summary of changes included with the patch:- ``` 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... 5 Changes in the LaneType to add a new carrier type field. 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. 8 New IR verification test. 9 New Micro-benchmark. 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. Out of above change 7b consumes 40000+ LOC. Q. Why do we need wrapper assertions ? A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers I think all the tasks are related and since most of source/test are generated using scripts we should not go by the size of patch and review the templates files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3788233245 From dholmes at openjdk.org Fri Jan 23 05:15:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Jan 2026 05:15:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo wrote: >> Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. >> >> I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. >> >> I added the changes you suggested. > > My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. Patricio is right as usual. I was thinking that the check for enabled-after-notification was to ensure we always posted the event, but really it is to ensure that if we post the event, we only do it if it had been enabled before notification. Sorry for the to-and-fro Anton. Reasoning about this is tricky. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2719636203 From dholmes at openjdk.org Fri Jan 23 06:33:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Jan 2026 06:33:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name I was hoping one of our container experts would jump in, but this seems okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3695895003 From stuefe at openjdk.org Fri Jan 23 07:04:44 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Jan 2026 07:04:44 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Just piling on, sorry for bikeshedding... > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) I agree. > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) I would prefer if the hotspot did write the timestamp, because 1) The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) 2) adding it to the hotspot will automatically work for every version of jcmd (e.g., I usually just call "jcmd" and use whatever jcmd tool happens to be on the path on that particular machine, but no guarantee it comes from the target VM) > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3788641543 From aartemov at openjdk.org Fri Jan 23 09:05:58 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 23 Jan 2026 09:05:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Changed condition on when to post an event. - 8366659: Fixed whitespaces. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewers' comments. - 8366659: Fixed whitespace. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewers' comments, added comments, renamed tests. - 8366659: Modified the comment. - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=30 Stats: 1372 lines in 9 files changed: 889 ins; 444 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Fri Jan 23 09:06:00 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 23 Jan 2026 09:06:00 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo wrote: >> Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. >> >> I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. >> >> I added the changes you suggested. > > My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. Thanks @pchilano, I was not aware of that property of agents. With that in mind, it makes sense to check the state in the condition. Modified the code accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2720303739 From kevinw at openjdk.org Fri Jan 23 09:25:48 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 09:25:48 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 02:09:30 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring Thanks for your efforts on this. Yes, the bytes were Linux x64 specific. I was thinking that the check would be in a file that is platform/arch specific, and would check for the specific signal return method for that architecture. If we do this with symbol names, or by looking at the bytes, it looks odd to have a generic method in the symtab file or LinuxCDebugger/LinuxDebuggerLocal that recognises a signal return method from any platform. If it's simpler to use symbol names that's fine, but I'm saying if we implement the recognition in LinuxADM64CFrame, then it knows what platform/arch this is, and can check for the specific symbol or bytes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789252429 From sgehwolf at openjdk.org Fri Jan 23 09:37:34 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Failing GHA checks are infra related. `git clone` returned `500`... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789300277 From sgehwolf at openjdk.org Fri Jan 23 09:37:37 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:37 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 22:40:12 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > LGTM from i18n point of view. Probably needs more reviews from hotspot side @naotoj Could you please ack this again? The same change, just the bellsoft copyright left untouched. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789304289 From epeter at openjdk.org Fri Jan 23 10:18:23 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:23 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <0xRSPGoZtGTXyFJEH5pvABR-qa2UZjNnQ2mXCxbYP4U=.ac7ab717-3adf-4910-a333-dd15b3fedd32@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja Thanks for your response. And thanks for the list of changes included in the patch :) It seems to me, many of these subtasks you mention could be done as separate tasks prior to the Float16Vector and auto-vectorizer work: 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. And 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. And in the below at least changes that don't include the Float16Vector: 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... Probably also this: 5 Changes in the LaneType to add a new carrier type field. And maybe also this, as long as it is not Float16 specific: 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. For `7`, probably only the `7b` part, since `7a` is about Float16Vector. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. Parts 8, 9, 10 seem Float16Vector specific, so those should stay here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789507594 From epeter at openjdk.org Fri Jan 23 10:18:26 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 04:24:57 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring and cleanups The goal of separating these is that reviewing is much easier, and so we can reach a higher confidence in the quality of the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789510739 From kevinw at openjdk.org Fri Jan 23 11:14:20 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 11:14:20 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Thanks Thomas yes it's kind of bikeshedding, but worth talking about hopefully. 8-) Glad you agree with the simplicity part. But you like the timestamp coming from the JVM: > The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) We don't want to do anything which prohibits possible future features, but also don't want to be constrained by what might possibly happen. 8-) So you're on the same hardware, running jcmd that may contact a container. jcmd logs the time. Is the time in the container that different? The new info contains the TZ/offset I think. We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. > adding it to the hotspot will automatically work for every version of jcmd Yes, this works both ways. The new jcmd will give timestamps when talking to older VMs. You can opt-in to new behaviour by choosing a later jcmd, without a JDK update in the app. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3789758234 From ysuenaga at openjdk.org Fri Jan 23 11:18:41 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 11:18:41 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: <5IIoH0kKvD83yyXWFSUW4vfLU6k1MbarmQZbBlcyt24=.79393c94-1520-421f-a6d5-d36edc4eddae@github.com> On Fri, 23 Jan 2026 09:23:02 GMT, Kevin Walls wrote: > Yes, the bytes were Linux x64 specific. I was thinking that the check would be in a file that is platform/arch specific, and would check for the specific signal return method for that architecture. However the bytes might be different - where does signal trampoline comes from (libc, vDSO), how is it implemented (whether `mov $0xf, %rax` is always come first) > If we do this with symbol names, or by looking at the bytes, it looks odd to have a generic method in the symtab file or LinuxCDebugger/LinuxDebuggerLocal that recognises a signal return method from any platform. AFAICS name of signal trampoline is `__restore_rt`, `__kernel_sigreturn`, or `__kernel_rt_sigreturn` on AMD64 / AArch64. They do not have architecture-dependent string. Thus I defined it in LinuxDebugger.java, and I will use it in other CFrame implementation like LinuxAArch64CFrame. I think it is not so complex because we just add a new name to `LinuxDebugger.SIGHANDLER_NAMES`, and tweak how can we get register values in each CFrame implementation like LinuxAMD64CFrame if we want to support new architecture. I want to support DWARF on both AMD64 and AArch64. Thus I make change carefully we can separate DWARF parser easily in near future. (I will start it after few patches - add support for frameless function and vDSO) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789774825 From ysuenaga at openjdk.org Fri Jan 23 11:46:46 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 11:46:46 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:23:02 GMT, Kevin Walls wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring > > Thanks for your efforts on this. > > Yes, the bytes were Linux x64 specific. I was thinking that the check would be in a file that is platform/arch specific, and would check for the specific signal return method for that architecture. > > If we do this with symbol names, or by looking at the bytes, it looks odd to have a generic method in the symtab file or LinuxCDebugger/LinuxDebuggerLocal that recognises a signal return method from any platform. > > If it's simpler to use symbol names that's fine, but I'm saying if we implement the recognition in LinuxADM64CFrame, then it knows what platform/arch this is, and can check for the specific symbol or bytes. glibc has following comments in sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c. It is better to check both function name and instruction bytes. @kevinjwalls What do you think? /* NOTE: Please think twice before making any changes to the bits of code below. GDB needs some intimate knowledge about it to recognize them as signal trampolines, and make backtraces through signal handlers work right. Important are both the names (__restore_rt) and the exact instruction sequence. If you ever feel the need to make any changes, please notify the appropriate GDB maintainer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789868617 From kevinw at openjdk.org Fri Jan 23 11:46:48 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 11:46:48 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 02:09:30 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 560: > 558: struct elf_symbol* sym = &(symtab->symbols[n]); > 559: if (sym->name != NULL && > 560: offset >= sym->offset && offset <= sym->offset + sym->size) { Good to have this issue not affecting the symtab file. Is this change part of reverting the file, or is it needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2720874831 From ysuenaga at openjdk.org Fri Jan 23 11:50:00 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 11:50:00 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 11:43:38 GMT, Kevin Walls wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 560: > >> 558: struct elf_symbol* sym = &(symtab->symbols[n]); >> 559: if (sym->name != NULL && >> 560: offset >= sym->offset && offset <= sym->offset + sym->size) { > > Good to have this issue not affecting the symtab file. > Is this change part of reverting the file, or is it needed? It is required because `sym->size` is zero on my environment (glibc-2.42-5.fc43.x86_64). Maybe it should be handled as special case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2720885766 From kevinw at openjdk.org Fri Jan 23 12:01:17 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 12:01:17 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 02:09:30 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring I didn't think there were too many combinations of bytes, and they seem as stable as anything else we depend on here, so my thinking was it was quite a robust check. Looks like gdb uses both but we don't need to deep dive into its workings right now. I think it's fine to continue using the symbol name as you are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789916226 From kevinw at openjdk.org Fri Jan 23 12:01:19 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 12:01:19 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 11:47:22 GMT, Yasumasa Suenaga wrote: >> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 560: >> >>> 558: struct elf_symbol* sym = &(symtab->symbols[n]); >>> 559: if (sym->name != NULL && >>> 560: offset >= sym->offset && offset <= sym->offset + sym->size) { >> >> Good to have this issue not affecting the symtab file. >> Is this change part of reverting the file, or is it needed? > > It is required because `sym->size` is zero on my environment (glibc-2.42-5.fc43.x86_64). > Maybe it should be handled as special case. Right, we have been here before with recognising symbols when PC is off the end of the defined symbol size in a different issue. I think then we (you!) tried hard not to simply recognise all symbols as being a byte larger than they really are. sym->size for the specific symbol we care about here is zero? Yes I'm seeing 0 size for __restore_rt also. Comparing offset == sym->offset as an alternative condition, without using sym->size would work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2720916096 From naoto at openjdk.org Fri Jan 23 13:20:02 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jan 2026 13:20:02 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Looks fine. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3697432626 From ysuenaga at openjdk.org Fri Jan 23 13:30:36 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 13:30:36 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v6] In-Reply-To: References: Message-ID: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Add is_in() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/d1864610..e70d1115 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=04-05 Stats: 15 lines in 1 file changed: 13 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Fri Jan 23 13:30:38 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 13:30:38 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 11:57:40 GMT, Kevin Walls wrote: >> It is required because `sym->size` is zero on my environment (glibc-2.42-5.fc43.x86_64). >> Maybe it should be handled as special case. > > Right, we have been here before with recognising symbols when PC is off the end of the defined symbol size in a different issue. I think then we (you!) tried hard not to simply recognise all symbols as being a byte larger than they really are. > > sym->size for the specific symbol we care about here is zero? Yes I'm seeing 0 size for __restore_rt also. > > Comparing offset == sym->offset as an alternative condition, without using sym->size would work? Good catch! But I feel conditions in `if` statement long a bit. So I added convenience function to check address range as `is_in()` and it works. How about this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2721192573 From kevinw at openjdk.org Fri Jan 23 13:54:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 13:54:39 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 13:27:19 GMT, Yasumasa Suenaga wrote: >> Right, we have been here before with recognising symbols when PC is off the end of the defined symbol size in a different issue. I think then we (you!) tried hard not to simply recognise all symbols as being a byte larger than they really are. >> >> sym->size for the specific symbol we care about here is zero? Yes I'm seeing 0 size for __restore_rt also. >> >> Comparing offset == sym->offset as an alternative condition, without using sym->size would work? > > Good catch! But I feel conditions in `if` statement long a bit. So I added convenience function to check address range as `is_in()` and it works. How about this? Yes no problem with that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2721279690 From kevinw at openjdk.org Fri Jan 23 13:57:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 13:57:39 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v6] In-Reply-To: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> References: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> Message-ID: On Fri, 23 Jan 2026 13:30:36 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add is_in() Looks good to me. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29023#pullrequestreview-3697596990 From duke at openjdk.org Fri Jan 23 15:02:09 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 15:02:09 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Kevin, Thomas, thank you very much for comments. Indeed. The way `jcmd` is implemented currently and in older JDKs, the tool does not question arguments following PID. One more thing to keep in mind. The is a use case with a chain of commands passed to `jcmd`. With this MR we can timestamp per command: $ cat input.txt -t VM.version -t VM.version $ jcmd -f input.txt 51721: 2026-01-23T14:58:28.515+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 2026-01-23T14:58:28.518+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 The timestamping implemented in `JCmd.java` would print timestamp only once at the beginning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3790630542 From duke at openjdk.org Fri Jan 23 15:56:15 2026 From: duke at openjdk.org (duke) Date: Fri, 23 Jan 2026 15:56:15 GMT Subject: Withdrawn: 8336881: [Linux] Support for hierarchical limits for Metrics In-Reply-To: References: Message-ID: <0l0fSe20dOlVvwouhazq9lxFYRD7w_mMnltTrcpeJIw=.b629c441-6b69-44ef-abb2-7008692b2382@github.com> On Mon, 22 Jul 2024 16:56:00 GMT, Severin Gehwolf wrote: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20280 From duke at openjdk.org Fri Jan 23 16:26:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 16:26:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v5] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": > > jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) > * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: tweaked help working for -t flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/f0e39a34..7371f3c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From sgehwolf at openjdk.org Fri Jan 23 16:55:22 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:55:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3791233146 From sgehwolf at openjdk.org Fri Jan 23 16:58:50 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:58:50 GMT Subject: Integrated: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. This pull request has now been integrated. Changeset: 3fb118a2 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3fb118a29ed68f2fbb64de45468b0f014fa01890 Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod 8375692: Hotspot container tests assert with non-ascii vendor name Reviewed-by: naoto, dholmes, syan ------------- PR: https://git.openjdk.org/jdk/pull/29315 From cjplummer at openjdk.org Fri Jan 23 17:50:35 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Jan 2026 17:50:35 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v6] In-Reply-To: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> References: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> Message-ID: On Fri, 23 Jan 2026 13:30:36 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add is_in() src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 555: > 553: static bool is_in(uintptr_t offset, struct elf_symbol* sym) { > 554: if (offset == sym->offset) { > 555: // offset points the top of the symbol Suggestion: // offset points to the top of the symbol ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2722193480 From cjplummer at openjdk.org Fri Jan 23 17:50:36 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Jan 2026 17:50:36 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v6] In-Reply-To: References: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> Message-ID: On Fri, 23 Jan 2026 17:33:59 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Add is_in() > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 555: > >> 553: static bool is_in(uintptr_t offset, struct elf_symbol* sym) { >> 554: if (offset == sym->offset) { >> 555: // offset points the top of the symbol > > Suggestion: > > // offset points to the top of the symbol This code is now confusing to read without knowledge that it is trying to solve the issue of a 0 sized symbol. I would suggest having it check `(sym->size == 0 && offset == sym->offset)`, and add a comment explaining why, and then the check below should be reverted back to `offset >= 0` instead of `offset > 0`. It is confusing to not have it check the full address range, especially since the comment indicates that it does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2722233077 From dcubed at openjdk.org Fri Jan 23 20:13:03 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Jan 2026 20:13:03 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:05:58 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Changed condition on when to post an event. > - 8366659: Fixed whitespaces. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments. > - 8366659: Fixed whitespace. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments, added comments, renamed tests. > - 8366659: Modified the comment. > - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad I last reviewed v25 and I tried to use the "Changes since you last reviewed" link, but I couldn't make sense of what I was seeing in the comparison from v25 -> v30. I'm gonna have to go back and do another crawl thru review here. Is it just me or has this patch (not counting the test refactoring) gotten really big? I realize that what we're trying to fix here is extremely complicated hence the size of the corrections. The bigger the patch, the harder it is to backport, but I don't know if we have any plans to backport this at all. Also, I don't see a root cause analysis in the bug report so we don't know how far back this issue goes. I suppose we could morph the new tests into something standalone that doesn't depend on anything in the current test suites and then work our way backward thru the LTS releases to see how far back this goes... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3792172270 From dcubed at openjdk.org Fri Jan 23 22:12:39 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Jan 2026 22:12:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: Message-ID: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> On Fri, 23 Jan 2026 09:05:58 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Changed condition on when to post an event. > - 8366659: Fixed whitespaces. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments. > - 8366659: Fixed whitespace. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments, added comments, renamed tests. > - 8366659: Modified the comment. > - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad I've made two complete read-thrus today. Just a couple comments about the changes as they are in v30. src/hotspot/share/runtime/objectMonitor.cpp line 1942: > 1940: } > 1941: > 1942: JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); OK so this effectively polls and handles a pending suspend request. That does not guarantee that another suspend request won't be pending again (and handled in the `JvmtiExport::post_monitor_waited()` call). src/hotspot/share/runtime/objectMonitor.cpp line 2099: > 2097: // move the add-to-entry_list operation, above, outside the critical section > 2098: // protected by _wait_set_lock. In practice that's not useful. With the > 2099: // exception of wait() timeouts and interrupts the monitor owner nit: extra space before wait. src/hotspot/share/runtime/objectMonitor.cpp line 2242: > 2240: // once we re-acquire the monitor we know if we need to throw IE or not. > 2241: ObjectWaiter::TStates state = node->TState; > 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, ""); assert with multiple conditions should output the values so we know exactly what condition failed. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3699805855 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722940869 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722949992 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722983763 From ysuenaga at openjdk.org Sat Jan 24 01:44:43 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 01:44:43 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v7] In-Reply-To: References: Message-ID: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c Co-authored-by: Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/e70d1115..ddc0e0f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Sat Jan 24 02:11:20 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 02:11:20 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v8] In-Reply-To: References: Message-ID: <9QoTtn4zDr7yFmjprB7cAp0ByymTOkMiWNbcn2NRGgM=.76ac00e3-710b-47c1-a866-2045264f3ee5@github.com> > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29023/files - new: https://git.openjdk.org/jdk/pull/29023/files/ddc0e0f7..f3b35980 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29023&range=06-07 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29023/head:pull/29023 PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Sat Jan 24 02:11:23 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 02:11:23 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v6] In-Reply-To: References: <7m6jsNAeAfG2yv8lap6rfUiqzpW_mV8dNxd8U0zhr9k=.561069ac-5296-4c57-b731-87e200c3fd07@github.com> Message-ID: On Fri, 23 Jan 2026 17:47:38 GMT, Chris Plummer wrote: >> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 555: >> >>> 553: static bool is_in(uintptr_t offset, struct elf_symbol* sym) { >>> 554: if (offset == sym->offset) { >>> 555: // offset points the top of the symbol >> >> Suggestion: >> >> // offset points to the top of the symbol > > This code is now confusing to read without knowledge that it is trying to solve the issue of a 0 sized symbol. I would suggest having it check `(sym->size == 0 && offset == sym->offset)`, and add a comment explaining why, and then the check below should be reverted back to `offset >= 0` instead of `offset > 0`. It is confusing to not have it check the full address range, especially since the comment indicates that it does. I fixed the conditions, and updated comments. Could you review again? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2723428565 From cjplummer at openjdk.org Sat Jan 24 03:05:51 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 24 Jan 2026 03:05:51 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v8] In-Reply-To: <9QoTtn4zDr7yFmjprB7cAp0ByymTOkMiWNbcn2NRGgM=.76ac00e3-710b-47c1-a866-2045264f3ee5@github.com> References: <9QoTtn4zDr7yFmjprB7cAp0ByymTOkMiWNbcn2NRGgM=.76ac00e3-710b-47c1-a866-2045264f3ee5@github.com> Message-ID: On Sat, 24 Jan 2026 02:11:20 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix Looks good. Thanks! ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29023#pullrequestreview-3700505466 From ysuenaga at openjdk.org Sat Jan 24 08:43:52 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 08:43:52 GMT Subject: RFR: 8374482: SA does not handle signal handler frame in mixed jstack [v8] In-Reply-To: <9QoTtn4zDr7yFmjprB7cAp0ByymTOkMiWNbcn2NRGgM=.76ac00e3-710b-47c1-a866-2045264f3ee5@github.com> References: <9QoTtn4zDr7yFmjprB7cAp0ByymTOkMiWNbcn2NRGgM=.76ac00e3-710b-47c1-a866-2045264f3ee5@github.com> Message-ID: On Sat, 24 Jan 2026 02:11:20 GMT, Yasumasa Suenaga wrote: >> SA does not handle signal handler frame in mixed jstack as following: >> >> >> ----------------- 1789 ----------------- >> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f6551c0e735 __GI_abort + 0x8b >> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 >> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 >> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b >> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e >> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 >> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 >> 0x00007f6551c27290 ???????? >> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) >> 0x00007f6534000849 >> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 >> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba >> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 >> 0x00007f6551e0582d JavaMain + 0xe4d >> 0x00007f6551c7f464 start_thread + 0x2e4 >> >> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). >> >> It should be like following: >> >> >> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a >> 0x00007fdbd267b290 >> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 >> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) >> >> >> This is long standing bug (since JDK 9 at least). > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix Thanks a lot for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3794237821 From lmesnik at openjdk.org Sat Jan 24 08:44:29 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 24 Jan 2026 08:44:29 GMT Subject: RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread Message-ID: The [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread disables posting ResourceExhausted events on CompilerThread because it can't post event. The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading). So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread. Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource. It is hard generate OOME in the CompilerThread to test this fix. The fix was tested by patch that generated event for codecache exchausting and new test. https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1 ------------- Commit messages: - 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread Changes: https://git.openjdk.org/jdk/pull/29397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8214294 Stats: 47 lines in 3 files changed: 37 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29397/head:pull/29397 PR: https://git.openjdk.org/jdk/pull/29397 From ysuenaga at openjdk.org Sat Jan 24 08:47:11 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 08:47:11 GMT Subject: Integrated: 8374482: SA does not handle signal handler frame in mixed jstack In-Reply-To: References: Message-ID: On Sat, 3 Jan 2026 10:22:25 GMT, Yasumasa Suenaga wrote: > SA does not handle signal handler frame in mixed jstack as following: > > > ----------------- 1789 ----------------- > "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f6551c0e735 __GI_abort + 0x8b > 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19 > 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579 > 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b > 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e > 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0 > 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38 > 0x00007f6551c27290 ???????? > 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame) > 0x00007f6534000849 > 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9 > 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba > 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164 > 0x00007f6551e0582d JavaMain + 0xe4d > 0x00007f6551c7f464 start_thread + 0x2e4 > > 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`). > > It should be like following: > > > 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a > 0x00007fdbd267b290 > 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18 > 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame) > > > This is long standing bug (since JDK 9 at least). This pull request has now been integrated. Changeset: a3b1aa9f Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/a3b1aa9f7dce30a1c5967cb15a5d523e3d7ea72d Stats: 189 lines in 6 files changed: 179 ins; 1 del; 9 mod 8374482: SA does not handle signal handler frame in mixed jstack Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/29023 From ysuenaga at openjdk.org Sat Jan 24 15:20:50 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 15:20:50 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame Message-ID: [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline. However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only. 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206 DW_CFA_nop DW_CFA_nop DW_CFA_nop Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java: 0x00007f14d500204d os::abort(bool, void const*, void const*) [clone .co ld] + 0x4 0x00007f14d6bd0001 VMError::report_and_die(int, char const*, char const *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c onst*, int, unsigned long) + 0x6f1 0x00007f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig ned char*, void const*, void const*, char const*, ...) + 0x88 0x00007f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig ned char*, void const*, void const*) + 0x58 0x00007f14d68ff1ba JVM_handle_linux_signal + 0x42a 0x00007f14d7964290 0x00007f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash 0x00007f14be7468ba ----------System.err:(20/1429)---------- java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) This PR is not only the fix, but also treat RBP for unwinder robustness. Thus the patch is large... ------------- Commit messages: - 8376264: Mixed jstack could not unwind optimized frame Changes: https://git.openjdk.org/jdk/pull/29398/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376264 Stats: 171 lines in 7 files changed: 46 ins; 74 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/29398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29398/head:pull/29398 PR: https://git.openjdk.org/jdk/pull/29398 From ysuenaga at openjdk.org Sun Jan 25 04:02:38 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 25 Jan 2026 04:02:38 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO Message-ID: Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a 0x00007faae4ad9290 0x00007faae4cd8e69 ???????? 0x00007faaca78ffa1 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) It should be: 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a 0x00007fb584fd9290 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 0x00007fb56a78f321 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. ------------- Commit messages: - 8376269: Mixed jstack cannot find function in vDSO Changes: https://git.openjdk.org/jdk/pull/29400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376269 Stats: 129 lines in 5 files changed: 115 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29400/head:pull/29400 PR: https://git.openjdk.org/jdk/pull/29400 From jbhateja at openjdk.org Sun Jan 25 07:05:40 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 07:05:40 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v15] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/72d15568..0891bc70 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=13-14 Stats: 822 lines in 48 files changed: 14 ins; 306 del; 502 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Sun Jan 25 08:00:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 08:00:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v16] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Refactoring vectorIntrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/0891bc70..aeba2e68 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=14-15 Stats: 150 lines in 1 file changed: 74 ins; 14 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From alanb at openjdk.org Sun Jan 25 08:26:50 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Jan 2026 08:26:50 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:40:06 GMT, Yasumasa Suenaga wrote: >> [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. >> >> In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo I've tied up the CSR and added myself as Reviewer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29355#issuecomment-3796191287 From alanb at openjdk.org Sun Jan 25 08:26:52 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Jan 2026 08:26:52 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: <0653pVD4jsN8giX-aMprqCvw8Wth2tSSmKzV2wdFrNE=.fe750a26-3381-4f1b-a2eb-e4c1b07b10d1@github.com> Message-ID: On Thu, 22 Jan 2026 13:47:27 GMT, Yasumasa Suenaga wrote: >> Can you please provide an example where IOException is thrown? The code in the catch block to use MonitoredHost.getMonitoredHost is surprising (the only dependency on jvmstat should be in the enumerate/list implementation). >> >> If URISyntaxException is not possible then it would be okay to throw an AssertionError or InternalError here. >> >> It would be useful to get an example or two of when MonitorException is thrown. That seems a reason candidate to wrap in an AttachOperationFailedException but I think have a specific example or two would help the discussion. >> >> It would be good to re-flow the comment in findTargetProcessTmpDirectory to reduce the wildly long lines. Right now it is really hard to look at the changes side-by-side. > >> Can you please provide an example where IOException is thrown? > > I could not produce IOException, but it might occur if filesystem is broken. > AccessDeniedException would happen as following. We can see it easy on attach to rootless container. > > # ./jcmd 1 VM.version > 1: > java.nio.file.AccessDeniedException: /proc/1/root/tmp > at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113) > at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391) > at java.base/java.nio.file.Files.isSameFile(Files.java:1418) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:280) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:236) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:87) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > > >> It would be useful to get an example or two of when MonitorException is thrown. > > As I said before, I cannot find out the location to throw MonitorException in JDK source around attach mechanism, but it might happen if the user uses custom attach provider. Anyway it is checked exception, so it shouldn't ignore or raise assertion error. Okay, I think we can go with wrapping these exceptions with AttachOperationFailedException. Are you planning to re-flow/cleanup findTargetProcessTmpDirectory as part of this PR? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2725111955 From ysuenaga at openjdk.org Sun Jan 25 11:02:33 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 25 Jan 2026 11:02:33 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 08:23:03 GMT, Alan Bateman wrote: > I've tied up the CSR and added myself as Reviewer. Thanks! I set the status to "Finalized". ------------- PR Comment: https://git.openjdk.org/jdk/pull/29355#issuecomment-3796435517 From ysuenaga at openjdk.org Sun Jan 25 11:02:32 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 25 Jan 2026 11:02:32 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v3] In-Reply-To: References: Message-ID: > [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. > > In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Update comments in findTargetProcessTmpDirectory() - Throw AssertionError when URISyntaxException happens at findTargetProcessTmpDirectory() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29355/files - new: https://git.openjdk.org/jdk/pull/29355/files/c9051cde..b6dbde9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29355&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29355&range=01-02 Stats: 26 lines in 1 file changed: 11 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29355/head:pull/29355 PR: https://git.openjdk.org/jdk/pull/29355 From ysuenaga at openjdk.org Sun Jan 25 11:02:34 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 25 Jan 2026 11:02:34 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v2] In-Reply-To: References: <0653pVD4jsN8giX-aMprqCvw8Wth2tSSmKzV2wdFrNE=.fe750a26-3381-4f1b-a2eb-e4c1b07b10d1@github.com> Message-ID: On Sun, 25 Jan 2026 08:24:39 GMT, Alan Bateman wrote: >>> Can you please provide an example where IOException is thrown? >> >> I could not produce IOException, but it might occur if filesystem is broken. >> AccessDeniedException would happen as following. We can see it easy on attach to rootless container. >> >> # ./jcmd 1 VM.version >> 1: >> java.nio.file.AccessDeniedException: /proc/1/root/tmp >> at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) >> at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108) >> at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113) >> at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391) >> at java.base/java.nio.file.Files.isSameFile(Files.java:1418) >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:280) >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:236) >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:87) >> at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) >> at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) >> >> >>> It would be useful to get an example or two of when MonitorException is thrown. >> >> As I said before, I cannot find out the location to throw MonitorException in JDK source around attach mechanism, but it might happen if the user uses custom attach provider. Anyway it is checked exception, so it shouldn't ignore or raise assertion error. > > Okay, I think we can go with wrapping these exceptions with AttachOperationFailedException. > > Are you planning to re-flow/cleanup findTargetProcessTmpDirectory as part of this PR? @AlanBateman I updated this PR: - Throw `AssertionError` if `URISyntaxException` happens. - Updated comment lines (at most 80 chars) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29355#discussion_r2725375537 From duke at openjdk.org Mon Jan 26 03:52:16 2026 From: duke at openjdk.org (Kent Dong) Date: Mon, 26 Jan 2026 03:52:16 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into JDK-8364343 > - simplify assert > - Merge branch 'master' into JDK-8364343 > - rebind in end_transition only for mount case > - Fix comment in inline_native_vthread_start_transition > - missing to initialize _is_disabler_at_start > - More changes from Coleen's review > - Drop VTMS from names > - keep preexisting rebind order for mount > - Remove INCLUDE_JVMTI macro > - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce Hi guys, would this patch be backported to JDK 25? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3797793059 From ysuenaga at openjdk.org Mon Jan 26 07:31:44 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 26 Jan 2026 07:31:44 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: Message-ID: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> > [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline. > However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only. > > > 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206 > DW_CFA_nop > DW_CFA_nop > DW_CFA_nop > > > Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java: > > > 0x00007f14d500204d os::abort(bool, void const*, void const*) [clone .co > ld] + 0x4 > 0x00007f14d6bd0001 VMError::report_and_die(int, char const*, char const > *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c > onst*, int, unsigned long) + 0x6f1 > 0x00007f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig > ned char*, void const*, void const*, char const*, ...) + 0x88 > 0x00007f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig > ned char*, void const*, void const*) + 0x58 > 0x00007f14d68ff1ba JVM_handle_linux_signal + 0x42a > 0x00007f14d7964290 > 0x00007f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash > 0x00007f14be7468ba > ----------System.err:(20/1429)---------- > java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.j... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring for simplifying ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29398/files - new: https://git.openjdk.org/jdk/pull/29398/files/9a8c7ec8..ecdb4423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29398&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29398&range=00-01 Stats: 90 lines in 1 file changed: 36 ins; 42 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29398/head:pull/29398 PR: https://git.openjdk.org/jdk/pull/29398 From shade at openjdk.org Mon Jan 26 11:18:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 11:18:00 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev wrote: >> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. >> >> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. >> >> Shenandoah added a few asserts to catch these errors: >> SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) >> >> ...but G1 would also benefit from the similar safety mechanism. >> >> This PR strengthens the code to prevent future accidents. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc` >> - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] GHA, cross-compilation only > > Aleksey Shipilev 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: > > Some polishing Still looking for a second Reviewer, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3799053446 From alanb at openjdk.org Mon Jan 26 11:53:16 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Jan 2026 11:53:16 GMT Subject: RFR: 8376052: Use AttachOperationFailedException rather than AttachNotSupportedException in findTargetProcessTmpDirectory() [v3] In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 11:02:32 GMT, Yasumasa Suenaga wrote: >> [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed. >> >> In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments in findTargetProcessTmpDirectory() > - Throw AssertionError when URISyntaxException happens at findTargetProcessTmpDirectory() Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29355#pullrequestreview-3705692383 From jbhateja at openjdk.org Mon Jan 26 12:17:02 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Jan 2026 12:17:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Clanups - Refactoring vectorIntrinsics - Refactoring and cleanups - Refactoring and cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519675 lines in 224 files changed: 284942 ins; 233000 del; 1733 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From aartemov at openjdk.org Mon Jan 26 14:45:34 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 14:45:34 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/31779cad..a3f07b94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=30-31 Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Mon Jan 26 14:45:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 14:45:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> Message-ID: <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> On Fri, 23 Jan 2026 21:42:46 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Changed condition on when to post an event. >> - 8366659: Fixed whitespaces. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewers' comments. >> - 8366659: Fixed whitespace. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewers' comments, added comments, renamed tests. >> - 8366659: Modified the comment. >> - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad > > src/hotspot/share/runtime/objectMonitor.cpp line 1942: > >> 1940: } >> 1941: >> 1942: JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > > OK so this effectively polls and handles a pending suspend request. > That does not guarantee that another suspend request won't be pending > again (and handled in the `JvmtiExport::post_monitor_waited()` call). I may not fully understand the problem here, but isn't it that suspension requests will be processed in order of execution at relevant places in the code? If there are, for instance 2 of those, then n1 will be handled on L1939, n2 - inside of `JvmtiExport::post_monitor_waited()`, any further suspension request will be handled by the thread as soon as it runs into a check for suspension in the program flow. What exactly is the concern here? There is no harm to suspend the thread in both L1939 and L1942 as the thread is known not to be the successor. @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > src/hotspot/share/runtime/objectMonitor.cpp line 2099: > >> 2097: // move the add-to-entry_list operation, above, outside the critical section >> 2098: // protected by _wait_set_lock. In practice that's not useful. With the >> 2099: // exception of wait() timeouts and interrupts the monitor owner > > nit: extra space before wait. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2242: > >> 2240: // once we re-acquire the monitor we know if we need to throw IE or not. >> 2241: ObjectWaiter::TStates state = node->TState; >> 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, ""); > > assert with multiple conditions should output the values so we know exactly what condition failed. I added an error message and a small function to convert `ObjectWaiter::TState` to a `char*` for printing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865056 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865334 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865876 From epeter at openjdk.org Mon Jan 26 16:04:33 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:04:33 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? Currently, we are using `T_SHORT` for `Float16`, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800362594 From epeter at openjdk.org Mon Jan 26 16:36:39 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:36:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa I asked some people internally, and they seem to be _very_ opposed to a new BasicType. Because it goes across the JVM, as I can also see in your patch. Apparently, they wanted to avoid the use of new BasicTypes, mostly managed except for the new `T_FLAT_ELEMENT`. Using `T_SHORT` for `Float16` would be strongly preferred. I think it may be good to ask @fparain @rose00 @iwanowww @vnkozlov if they have opinions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800525049 From psandoz at openjdk.org Mon Jan 26 16:51:30 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Jan 2026 16:51:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800594113 From cjplummer at openjdk.org Mon Jan 26 19:33:49 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Jan 2026 19:33:49 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 03:49:17 GMT, Chris Plummer wrote: > The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: > > > if (core_pattern[0] == '|') { > written = jio_snprintf(buffer, bufferSize, > - ""%s" (or dumping to %s/core.%d)", > + ""%s" (alternatively, falling back to %s/core.%d)", > &core_pattern[1], p, current_process_id()); > > > CoreUtils was checking for "or ", but it needs to check for "alternatively...". > > Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. Ping again. I'd really like to get this pushed. There have been recent SA core file related changes, and more are to come, and without this change they are not being properly tested by our CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3801287714 From cjplummer at openjdk.org Mon Jan 26 19:33:53 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Jan 2026 19:33:53 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga wrote: >> [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline. >> However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only. >> >> >> 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206 >> DW_CFA_nop >> DW_CFA_nop >> DW_CFA_nop >> >> >> Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java: >> >> >> 0x00007f14d500204d os::abort(bool, void const*, void const*) [clone .co >> ld] + 0x4 >> 0x00007f14d6bd0001 VMError::report_and_die(int, char const*, char const >> *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c >> onst*, int, unsigned long) + 0x6f1 >> 0x00007f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*, char const*, ...) + 0x88 >> 0x00007f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*) + 0x58 >> 0x00007f14d68ff1ba JVM_handle_linux_signal + 0x42a >> 0x00007f14d7964290 >> 0x00007f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash >> 0x00007f14be7468ba >> ----------System.err:(20/1429)---------- >> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring for simplifying It looks like the only reason we don't currently see this failure in our CI is because the test is being skipped due to [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out to fix this, but it looks like it is best not to push it until this PR is first pushed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3801318858 From cjplummer at openjdk.org Mon Jan 26 19:37:39 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Jan 2026 19:37:39 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: References: Message-ID: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> > The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: > > > if (core_pattern[0] == '|') { > written = jio_snprintf(buffer, bufferSize, > - ""%s" (or dumping to %s/core.%d)", > + ""%s" (alternatively, falling back to %s/core.%d)", > &core_pattern[1], p, current_process_id()); > > > CoreUtils was checking for "or ", but it needs to check for "alternatively...". > > Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8375477_coreutils Merge - fix whitespace - get rid of unnecessary throws clause - fix zipped core file support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29284/files - new: https://git.openjdk.org/jdk/pull/29284/files/a79ef897..2ca1a223 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29284&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29284&range=00-01 Stats: 24318 lines in 663 files changed: 11478 ins; 4071 del; 8769 mod Patch: https://git.openjdk.org/jdk/pull/29284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29284/head:pull/29284 PR: https://git.openjdk.org/jdk/pull/29284 From cjplummer at openjdk.org Mon Jan 26 21:03:29 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Jan 2026 21:03:29 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Mon, 26 Jan 2026 19:21:59 GMT, Chris Plummer wrote: > It looks like the only reason we don't currently see this failure in our CI is because the test is being skipped due to [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out to fix this, but it looks like it is best not to push it until this PR is first pushed. Actually I see now it does still pass even when not skipped, but the output does contain the exception. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3801733809 From dholmes at openjdk.org Mon Jan 26 23:39:28 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jan 2026 23:39:28 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support test/lib/jdk/test/lib/util/CoreUtils.java line 224: > 222: // Find the core file name in the output. > 223: String coreWithPid; > 224: if (Platform.isLinux() && stringWithLocation.contains(ALT_LOCATION_STRING)) { Why is this only done for Linux when previously it was done for "not Windows"? What is the core message on macOS? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2729688156 From sspitsyn at openjdk.org Mon Jan 26 23:59:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 26 Jan 2026 23:59:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: On Mon, 26 Jan 2026 14:38:40 GMT, Anton Artemov wrote: > @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: - suspend 1, resume 1, suspend 2 I'll read it more carefully and provide update if needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2729724632 From cjplummer at openjdk.org Tue Jan 27 00:10:25 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 00:10:25 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Mon, 26 Jan 2026 23:36:52 GMT, David Holmes wrote: >> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8375477_coreutils >> Merge >> - fix whitespace >> - get rid of unnecessary throws clause >> - fix zipped core file support > > test/lib/jdk/test/lib/util/CoreUtils.java line 224: > >> 222: // Find the core file name in the output. >> 223: String coreWithPid; >> 224: if (Platform.isLinux() && stringWithLocation.contains(ALT_LOCATION_STRING)) { > > Why is this only done for Linux when previously it was done for "not Windows"? What is the core message on macOS? Message on Windows: `# Core dump will be written. Default location: C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\0\\hs_err_pid71004.mdmp` And then later in test output you see: getCoreFileLocation found stringWithLocation = C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp Found core file C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp, size = 361mb I don't have macOS info at the moment. I only ran on macosx-aarch64, and currently all the core file tests are problem listed on that platform. I'm doing a run now without them problem listed. Will have results shortly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2729744779 From cjplummer at openjdk.org Tue Jan 27 00:15:07 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 00:15:07 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Tue, 27 Jan 2026 00:07:35 GMT, Chris Plummer wrote: >> test/lib/jdk/test/lib/util/CoreUtils.java line 224: >> >>> 222: // Find the core file name in the output. >>> 223: String coreWithPid; >>> 224: if (Platform.isLinux() && stringWithLocation.contains(ALT_LOCATION_STRING)) { >> >> Why is this only done for Linux when previously it was done for "not Windows"? What is the core message on macOS? > > Message on Windows: > > `# Core dump will be written. Default location: C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\0\\hs_err_pid71004.mdmp` > > And then later in test output you see: > > > getCoreFileLocation found stringWithLocation = C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp > Found core file C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp, size = 361mb > > > I don't have macOS info at the moment. I only ran on macosx-aarch64, and currently all the core file tests are problem listed on that platform. I'm doing a run now without them problem listed. Will have results shortly. Oh, and the reason for not doing in a macOS is because this code is only applicatlbe if a linux core file handler is installed. See the comment immediately below. I don't see how it could ever benefit macOS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2729753120 From dcubed at openjdk.org Tue Jan 27 00:31:20 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 27 Jan 2026 00:31:20 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:45:34 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewer's comment. Thanks for addressing my comments. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3708613462 From cjplummer at openjdk.org Tue Jan 27 00:50:05 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 00:50:05 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: <8thMz4RLepWpbU_pTwK1dQEKUht_nVg1CCw_S5hZOrU=.81b60b7e-6fe4-4836-9925-53ed5f33cbf9@github.com> On Tue, 27 Jan 2026 00:12:08 GMT, Chris Plummer wrote: >> Message on Windows: >> >> `# Core dump will be written. Default location: C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\0\\hs_err_pid71004.mdmp` >> >> And then later in test output you see: >> >> >> getCoreFileLocation found stringWithLocation = C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp >> Found core file C:\\sb\\prod\\1769462715\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_core_file_tests\\scratch\\2\\hs_err_pid80292.mdmp, size = 361mb >> >> >> I don't have macOS info at the moment. I only ran on macosx-aarch64, and currently all the core file tests are problem listed on that platform. I'm doing a run now without them problem listed. Will have results shortly. > > Oh, and the reason for not doing in a macOS is because this code is only applicatlbe if a linux core file handler is installed. See the comment immediately below. I don't see how it could ever benefit macOS. >From macOS hs_err file: `# Core dump will be written. Default location: core.78827` >From the test output: getCoreFileLocation found stringWithLocation = core.78827 Found core file core.78827, size = 6660mb ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2729813708 From sspitsyn at openjdk.org Tue Jan 27 01:57:11 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Jan 2026 01:57:11 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case Message-ID: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. Testing: - TBD: Mach5 tiers 1-6 ------------- Commit messages: - 8373367: interp-only mechanism fails to work for carrier threads in a corner case Changes: https://git.openjdk.org/jdk/pull/29436/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373367 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From dholmes at openjdk.org Tue Jan 27 07:40:28 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Jan 2026 07:40:28 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into JDK-8364343 > - simplify assert > - Merge branch 'master' into JDK-8364343 > - rebind in end_transition only for mount case > - Fix comment in inline_native_vthread_start_transition > - missing to initialize _is_disabler_at_start > - More changes from Coleen's review > - Drop VTMS from names > - keep preexisting rebind order for mount > - Remove INCLUDE_JVMTI macro > - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce I've added a comment to the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3803589839 From jbhateja at openjdk.org Tue Jan 27 08:11:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 08:11:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <5a11-TYC046h3ro4YgCI4oSBFfyjUWlWA2I3pOMTF-k=.bfff183a-d825-45ba-bc75-d515337119be@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. > @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? > > Currently, we are using `T_SHORT` for `Float16`, right? Hi @eme64 , Currently in JDK mainline we pass element class as the lane type, problem with passing Float16.class is that its part of incubating module an we cannot declare a symbol for it in vmSymbols, thus if we pass Float16.class as element type we will need to do a fragile name based checks over element type to infer Float16 operation in inline expanders. To circumvent this problem started passing additional integer argument vector operation type (VECTOR_TYPE_FP16 / VECTOR_TYPE_PRIM) to intrinsic entry point. Paul suggested in his [prior comment](https://github.com/openjdk/jdk/pull/28002#issuecomment-3529452461) to add a new basicType for Float16 and instead of passing element class and vector operation type pass just the basicType since its already used in the LaneType. [Enum definitions of all the primitive basic types used in LaneType ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java*L153__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe1bY_kYW$) are as per JVM specification and in synchronism with [BasicType definition in VM side](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/globalDefinitions.hpp*L671__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe6e5uGFc$). VM also defines some custom basic types like T_METADATA, T_NARROWKLASS. If we just create new basic type on Java side, then there is a chance that its value may conflict with existing custom basic types in VM side. One solution is to maintain the synchronization b/w basic type assignment for primitive type only and not modify any VM side code since current scope of T_FLOAT16 is only limited to intrinsic entry point. Adding a new custom BasicType on VM side is not just a change in one place and is cumbersome and not desirable given that its used all across VM code. Thus there are following options :- 1/ Create new basicType T_FLOAT16 in Java side, add it to LaneType and pass only basic types as element type to intrinsic entry point and maintain an efficient interface 2/ Pass Float16.class as element type to Float16Vector operations and do a fragile and inefficient name base lookup in inline expander to infer Float16 vector IR. 3/ Extend both BasicType definition on Java side and VM side and keep them in synchronism but this is not desirable given that VM makes extensive use of BasicType. 4/ Pass short.class as element type and pass another argument vector operation kind to intrinsic entry point to differentiate b/w ShortVector and Float16Vector operations. 5/ Paul's suggestion to create proxy class in java.base module for Float16 type. I am inclined to go with solution 1, let me know if you have other solutions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3803701515 From aph at openjdk.org Tue Jan 27 10:03:29 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:03:29 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: <-kzq5g8d69uvOXdFDYPXAJas_rM5FsaFuro_AKjb5wE=.4ac4c903-0573-45b5-a0ab-f1d922ac8a31@github.com> On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/cpu/x86/templateTable_x86.cpp line 1856: > 1854: > 1855: // and begin the OSR nmethod > 1856: // Load the _hdr pointer from the nmethod into rscratch1 These comments are inappropriate. See [Rule 1: Comments should not duplicate the code.](https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731197298 From kevinw at openjdk.org Tue Jan 27 10:12:36 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 10:12:36 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:03:14 GMT, Eunbin Son wrote: >>> I removed lines 168-191 and keep the skip message at line 192. >> >> Then the bug and PR titles and descriptions have to be changed to match it. > > @sspitsyn Thank you. should I register a new bug report? Or, I think I can change this PR titles and descriptions. @thswlsqls Hi, are you able to edit the title of this PR to match the JBS issue? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3804274808 From aph at openjdk.org Tue Jan 27 10:12:39 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:12:39 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/share/code/nmethod.cpp line 487: > 485: void nmethod::set_deoptimized_done() { > 486: ConditionalMutexLocker ml(NMethodState_lock, !NMethodState_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); > 487: if (_hdr->_deoptimization_status != NMethodHeader::deoptimize_done) { // can't go backwards Suggestion: if (deoptimization_status() != deoptimize_done) { // can't go backwards Create an accessor for `deoptimization_status`. Why is it now necessary to use `NMethodHeader::`? src/hotspot/share/code/nmethod.cpp line 1301: > 1299: _hdr->_compiler_type = type; > 1300: _hdr->_orig_pc_offset = 0; > 1301: _hdr->_num_stack_arg_slots = 0; It'd be better to move this into a separate initializer for `NMethodHeader`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731224628 PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731235594 From aph at openjdk.org Tue Jan 27 10:29:45 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:29:45 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: <3AwMiUeGLhif3W4e5f3rf4AAakQgMatr7HanisLLUMk=.db6de600-3e3c-4028-89fd-cde55b8762d3@github.com> On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/share/code/nmethod.cpp line 1233: > 1231: _hdr->_has_flushed_dependencies = 0; > 1232: _hdr->_is_unlinked = 0; > 1233: _hdr->_load_reported = 0; // jvmti state Again, give `NMethodHeader` its own copy and initialize logic. src/hotspot/share/code/nmethod.cpp line 1460: > 1458: _hdr->_unwind_handler_offset = nm._hdr->_unwind_handler_offset; > 1459: _hdr->_num_stack_arg_slots = nm._hdr->_num_stack_arg_slots; > 1460: _hdr->_oops_size = nm._hdr->_oops_size; This stuff belongs in class `NMethodHeader` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731301721 PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731303752 From kevinw at openjdk.org Tue Jan 27 10:49:09 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 10:49:09 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: <3ROVqs2AeA6gv3XjGQJYpePhm7-HmcviyYnx7NoknvA=.e1b711e2-c044-472f-8552-8c9463c78eda@github.com> On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support test/lib/jdk/test/lib/util/CoreUtils.java line 237: > 235: * into this path. > 236: */ > 237: Matcher m = Pattern.compile(ALT_LOCATION_STRING + ".* ([^ ]+[^\\)])\\)?").matcher(stringWithLocation); Trying to understand the regex. 8-) os::get_core_path printed " (alternatively, falling back to %s/core.%d)" Do we need the initial .* in the regex? Would it be " ([^ ]+)\)" or " (.*)\)" Maybe there's some complication and the other [^\)])\)? is needed? Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2731396482 From kevinw at openjdk.org Tue Jan 27 10:51:08 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 10:51:08 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support Looks good, added one question. Also if the pattern is |/..../systemd-coredump then the core file ends up somewhere else entirely. We give a useful message when skipping, so no need to describe that here as well. There was an attempt to handle those cases but it's not realistic and should be removed in https://github.com/openjdk/jdk/pull/28984 - I pinged the submitter as that change was ready to go... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3804457396 From kevinw at openjdk.org Tue Jan 27 11:04:48 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 11:04:48 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed initialization bug in AOT cache sharing summary code src/hotspot/share/services/diagnosticCommand.cpp line 962: > 960: "R = has been redefined, " > 961: "S = is shared class (if -location then 's' indicates static 'd' indicates dynamic AOT cache)", > 962: "BOOLEAN", false, "false"), Not sure I understand the "if -location" in the text here and in the man page, as we print these flags always? Are the shared class/AOT related flags independent, like: R = has been redefined, S = is shared class, s = static shared class, d = AOT dynamic cache ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2731461130 From jbhateja at openjdk.org Tue Jan 27 12:30:31 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 12:30:31 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 16:48:11 GMT, Paul Sandoz wrote: > The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? Hi @PaulSandoz , We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3804950143 From jpbempel at openjdk.org Tue Jan 27 12:41:50 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 12:41:50 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Message-ID: ?retransformed Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL ------------- Commit messages: - add missing files - 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Changes: https://git.openjdk.org/jdk/pull/29445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376185 Stats: 487 lines in 6 files changed: 485 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From liach at openjdk.org Tue Jan 27 14:40:17 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:40:17 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:48:41 GMT, Jean-Philippe Bempel wrote: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Please add a copyright header for your affliation for the new files (.java, .jcod, .sh) that you add, or fallback to an Oracle copyright header. See https://openjdk.org/guide/#copyright-headers ------------- PR Comment: https://git.openjdk.org/jdk/pull/29445#issuecomment-3805583503 From jpbempel at openjdk.org Tue Jan 27 14:56:31 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 14:56:31 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: add copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29445/files - new: https://git.openjdk.org/jdk/pull/29445/files/33f92068..725f4edb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00-01 Stats: 93 lines in 4 files changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From cjplummer at openjdk.org Tue Jan 27 17:02:28 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 17:02:28 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <3ROVqs2AeA6gv3XjGQJYpePhm7-HmcviyYnx7NoknvA=.e1b711e2-c044-472f-8552-8c9463c78eda@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> <3ROVqs2AeA6gv3XjGQJYpePhm7-HmcviyYnx7NoknvA=.e1b711e2-c044-472f-8552-8c9463c78eda@github.com> Message-ID: On Tue, 27 Jan 2026 10:45:50 GMT, Kevin Walls wrote: >> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8375477_coreutils >> Merge >> - fix whitespace >> - get rid of unnecessary throws clause >> - fix zipped core file support > > test/lib/jdk/test/lib/util/CoreUtils.java line 237: > >> 235: * into this path. >> 236: */ >> 237: Matcher m = Pattern.compile(ALT_LOCATION_STRING + ".* ([^ ]+[^\\)])\\)?").matcher(stringWithLocation); > > Trying to understand the regex. 8-) > os::get_core_path printed " (alternatively, falling back to %s/core.%d)" > > Do we need the initial .* in the regex? > Would it be " ([^ ]+)\)" or " (.*)\)" > > Maybe there's some complication and the other [^\)])\)? is needed? Thanks TBH I didn't look into this pattern much because it was so ugly, but was working. I focused on just the start of the pattern, which is where the text that changed was. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2732978971 From kevinw at openjdk.org Tue Jan 27 17:11:11 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 17:11:11 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29284#pullrequestreview-3712433014 From kevinw at openjdk.org Tue Jan 27 17:11:15 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 17:11:15 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> <3ROVqs2AeA6gv3XjGQJYpePhm7-HmcviyYnx7NoknvA=.e1b711e2-c044-472f-8552-8c9463c78eda@github.com> Message-ID: On Tue, 27 Jan 2026 16:59:34 GMT, Chris Plummer wrote: >> test/lib/jdk/test/lib/util/CoreUtils.java line 237: >> >>> 235: * into this path. >>> 236: */ >>> 237: Matcher m = Pattern.compile(ALT_LOCATION_STRING + ".* ([^ ]+[^\\)])\\)?").matcher(stringWithLocation); >> >> Trying to understand the regex. 8-) >> os::get_core_path printed " (alternatively, falling back to %s/core.%d)" >> >> Do we need the initial .* in the regex? >> Would it be " ([^ ]+)\)" or " (.*)\)" >> >> Maybe there's some complication and the other [^\)])\)? is needed? Thanks > > TBH I didn't look into this pattern much because it was so ugly, but was working. I focused on just the start of the pattern, which is where the text that changed was. Oh I thought it was a change, due to the way the diff was on screen, but it's the same old ugly pattern. Suspect .* is matching nothing if the capture group actually finding the core file. If it's not part of the change it shouldn't hold this up... 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2733013556 From cjplummer at openjdk.org Tue Jan 27 17:24:26 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 17:24:26 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: <1GASEVPCCTbfG90LaKrGyKjl5kf4pORfhOrWBTnQIOw=.0c67596e-c7b3-4f66-8d7a-af1d42a4ad33@github.com> On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support @dholmes-ora Do you still have concerns regarding macSO? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3806476865 From larry.cable at oracle.com Tue Jan 27 17:28:12 2026 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 27 Jan 2026 09:28:12 -0800 Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <5e5cd1d5-e3bb-440a-abef-931d22d02f17@oracle.com> On 1/27/26 3:04 AM, Kevin Walls wrote: > On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable wrote: > >>> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >>> >>> effectively: >>> >>> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >>> >>> (where interim oops are null-checked) >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: fixed initialization bug in AOT cache sharing summary code > src/hotspot/share/services/diagnosticCommand.cpp line 962: > >> 960: "R = has been redefined, " >> 961: "S = is shared class (if -location then 's' indicates static 'd' indicates dynamic AOT cache)", >> 962: "BOOLEAN", false, "false"), > Not sure I understand the "if -location" in the text here and in the man page, as we print these flags always? > Are the shared class/AOT related flags independent, like: > > R = has been redefined, > S = is shared class, > s = static shared class, > d = AOT dynamic cache simple, if '-location' is specified the additional flags ('s' & 'd') will be displayed as appropriate, its a mechanism to add additional metadata while maintaining b/w compatibility for existing consumers of the content > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2731461130 From psandoz at openjdk.org Tue Jan 27 18:28:32 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 27 Jan 2026 18:28:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 12:27:46 GMT, Jatin Bhateja wrote: > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3806791602 From lmesnik at openjdk.org Tue Jan 27 18:59:36 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Jan 2026 18:59:36 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> On Tue, 27 Jan 2026 01:48:03 GMT, Serguei Spitsyn wrote: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 src/hotspot/share/prims/jvmtiThreadState.cpp line 127: > 125: thread->set_interp_only_mode(false); > 126: } > 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { wouldn't be better to move this into the beginning of ctor: if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { _thread = thread; _thread_saved = nullptr; } else { _thread_saved = thread; _thread = nullptr; } and might be add comments with explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2733381607 From kevinw at openjdk.org Tue Jan 27 19:14:33 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 19:14:33 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable wrote: >> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >> >> effectively: >> >> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >> >> (where interim oops are null-checked) > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8327246: fixed initialization bug in AOT cache sharing summary code Ah ok thanks Larry - we always may show 'S', but I missed the _location check before printing s and d. It surprises me that the flags that can be printed are dependent on the -location flag. As we only show _aot_static and dynamics if _location is set, I guess I expected one if (_location) check before the AOTMetaspace::in_aot_cache_static_region and (AOTMetaspace::in_aot_cache_dynamic_region checks. The "-location" help is: "Print class file (and AOT cache) location url (if available)" ..but it's more than that, it affects what flags we might print as well. Is it simpler to just show the flags always? Actually, we already have a problem that the "Some classes are annotated with flags.." text is part of the "-verbose" flag description, but that is wrong. It should be in the description() method in the .hpp file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3807013254 From larry.cable at oracle.com Tue Jan 27 19:42:11 2026 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 27 Jan 2026 11:42:11 -0800 Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <3d43e077-ea29-495e-9283-5067f5948fc9@oracle.com> On 1/27/26 11:14 AM, Kevin Walls wrote: > On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable wrote: > >>> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. >>> >>> effectively: >>> >>> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() >>> >>> (where interim oops are null-checked) >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: fixed initialization bug in AOT cache sharing summary code > Ah ok thanks Larry - we always may show 'S', but I missed the _location check before printing s and d. It surprises me that the flags that can be printed are dependent on the -location flag. > > As we only show _aot_static and dynamics if _location is set, I guess I expected one if (_location) check before the AOTMetaspace::in_aot_cache_static_region and (AOTMetaspace::in_aot_cache_dynamic_region checks. > > The "-location" help is: "Print class file (and AOT cache) location url (if available)" > ..but it's more than that, it affects what flags we might print as well. Is it simpler to just show the flags always? again it is my practice to avoid changes to existing formats. > > Actually, we already have a problem that the "Some classes are annotated with flags.." text is part of the "-verbose" flag description, but that is wrong. It should be in the description() method in the .hpp file? I'll check > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3807013254 From dholmes at openjdk.org Tue Jan 27 20:31:05 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Jan 2026 20:31:05 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <1GASEVPCCTbfG90LaKrGyKjl5kf4pORfhOrWBTnQIOw=.0c67596e-c7b3-4f66-8d7a-af1d42a4ad33@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> <1GASEVPCCTbfG90LaKrGyKjl5kf4pORfhOrWBTnQIOw=.0c67596e-c7b3-4f66-8d7a-af1d42a4ad33@github.com> Message-ID: <19AeRPhcE9W_dHcZUzbGEqYuk7OYuPGs9w1_KW6nzxw=.7be8ade5-4588-4dc1-acbb-35cbc465a115@github.com> On Tue, 27 Jan 2026 17:21:47 GMT, Chris Plummer wrote: > @dholmes-ora Do you still have concerns regarding macSO? I guess not. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3807382518 From duke at openjdk.org Tue Jan 27 20:39:14 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 27 Jan 2026 20:39:14 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v11] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: changes as per @kwalls last comments, improved help and optimized -location option checking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/341643a2..f2198458 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=09-10 Stats: 17 lines in 2 files changed: 2 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From cjplummer at openjdk.org Tue Jan 27 20:42:57 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 20:42:57 GMT Subject: RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2] In-Reply-To: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> References: <6nXjm_DmGqhzj8sLiVCHM4fTaPToiDDqbSdXTnC-_7g=.0583e28e-3442-4a56-840d-73caeab6213f@github.com> Message-ID: On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer wrote: >> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: >> >> >> if (core_pattern[0] == '|') { >> written = jio_snprintf(buffer, bufferSize, >> - ""%s" (or dumping to %s/core.%d)", >> + ""%s" (alternatively, falling back to %s/core.%d)", >> &core_pattern[1], p, current_process_id()); >> >> >> CoreUtils was checking for "or ", but it needs to check for "alternatively...". >> >> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8375477_coreutils > Merge > - fix whitespace > - get rid of unnecessary throws clause > - fix zipped core file support Thanks for the reviews Kevin and Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3807422287 From cjplummer at openjdk.org Tue Jan 27 20:42:57 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Jan 2026 20:42:57 GMT Subject: Integrated: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 03:49:17 GMT, Chris Plummer wrote: > The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for: > > > if (core_pattern[0] == '|') { > written = jio_snprintf(buffer, bufferSize, > - ""%s" (or dumping to %s/core.%d)", > + ""%s" (alternatively, falling back to %s/core.%d)", > &core_pattern[1], p, current_process_id()); > > > CoreUtils was checking for "or ", but it needs to check for "alternatively...". > > Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly. This pull request has now been integrated. Changeset: fa1b1d67 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/fa1b1d677ac492dfdd3110b9303a4c2b009046c8 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped Reviewed-by: lmesnik, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/29284 From xpeng at openjdk.org Tue Jan 27 21:08:26 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 21:08:26 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev wrote: >> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. >> >> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. >> >> Shenandoah added a few asserts to catch these errors: >> SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) >> >> ...but G1 would also benefit from the similar safety mechanism. >> >> This PR strengthens the code to prevent future accidents. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc` >> - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] GHA, cross-compilation only > > Aleksey Shipilev 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: > > Some polishing Thanks for generalize the safety mechanism. Looks good to me, and it is a nice PR to read. ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3713454244 From smarks at openjdk.org Tue Jan 27 22:08:03 2026 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 27 Jan 2026 22:08:03 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: References: Message-ID: <79hDmxh1U08HsZCcmmVv8RgZm_CTAT-SdIpNVzYnAyE=.2ba9385a-d580-4fa3-ae3e-820daebb291a@github.com> On Tue, 27 Jan 2026 10:09:28 GMT, Kevin Walls wrote: >> @sspitsyn Thank you. should I register a new bug report? Or, I think I can change this PR titles and descriptions. > > @thswlsqls Hi, are you able to edit the title of this PR to match the JBS issue? Note that the `\s` escape sequence denotes a SPACE character (U+0020) and not a BACKSPACE character as stated in the description. Thus the regex might actually match the relevant line in the example from @kevinjwalls' comment: # cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F if the character following `-coredump` is a space character. Of course this is moot if the decision is to remove this stuff entirely... but it appears that the original code might have worked, at least in some cases. That might resolve the "How could this ever have worked?!?" mystery. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3807760773 From duke at openjdk.org Tue Jan 27 22:14:33 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 27 Jan 2026 22:14:33 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v12] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: updated VM.classes description as per previous changes to -help text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/f2198458..4b1bb228 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=10-11 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From amenkov at openjdk.org Wed Jan 28 00:16:24 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 28 Jan 2026 00:16:24 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case In-Reply-To: <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: On Tue, 27 Jan 2026 18:50:13 GMT, Leonid Mesnik wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > src/hotspot/share/prims/jvmtiThreadState.cpp line 127: > >> 125: thread->set_interp_only_mode(false); >> 126: } >> 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > > wouldn't be better to move this into the beginning of ctor: > > if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > _thread = thread; > _thread_saved = nullptr; > } else { > _thread_saved = thread; > _thread = nullptr; > } > > and might be add comments with explanation. +1 And have you tried to implement a test for the case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2734329325 From dholmes at openjdk.org Wed Jan 28 02:30:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 02:30:14 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: On Mon, 26 Jan 2026 23:56:03 GMT, Serguei Spitsyn wrote: >> I may not fully understand the problem here, but isn't it that suspension requests will be processed in order of execution at relevant places in the code? >> >> If there are, for instance 2 of those, then n1 will be handled on L1939, n2 - inside of `JvmtiExport::post_monitor_waited()`, any further suspension request will be handled by the thread as soon as it runs into a check for suspension in the program flow. What exactly is the concern here? There is no harm to suspend the thread in both L1939 and L1942 as the thread is known not to be the successor. >> >> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > >> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > > It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: > - suspend 1, resume 1, suspend 2 > > The `JvmtiExport::post_monitor_waited()` has a recursive call to `ThreadStateTransition::transition_from_native()` upon return from event callback. There is a suspend point there. > I'll read it more carefully and provide update if needed. IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2734584373 From dholmes at openjdk.org Wed Jan 28 02:38:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 02:38:29 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:45:34 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewer's comment. A couple of nits but otherwise I think everything has been addressed and that the code will do what we want/expect. Thanks src/hotspot/share/runtime/objectMonitor.cpp line 2244: > 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, > 2243: "was not notified and is not in the right state: was_notified = %s, state = %s", > 2244: was_notified ? "true" : "false", node->getTStateName(state)); Suggestion: assert(was_notified || state == ObjectWaiter::TS_RUN, "was not notified and is not in the right state: was_notified = %s, state = %s", was_notified ? "true" : "false", node->getTStateName(state)); Fix indent. Printing was_notified is redundant though as the assert can only fail if it is false. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3714312102 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2734592403 From ysuenaga at openjdk.org Wed Jan 28 04:22:01 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 28 Jan 2026 04:22:01 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Mon, 26 Jan 2026 21:00:41 GMT, Chris Plummer wrote: > Actually I see now it does still pass even when not skipped, but the output does contain the exception. Yes. New test (TestJhsdbJstackMixedCore.java) introduced in JDK-8374482 highlighted a problem at the function which does not have prologue (in context of calling convention) and its FDE is NOP only. It tends to happen on optimization by compiler. Thus it is different from JDK-8375477. We need to improve DWARF parser and stack unwinder like this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3808862526 From eirbjo at openjdk.org Wed Jan 28 06:00:45 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 06:00:45 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 Message-ID: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. Test only change/cleanup. `noreg-self` ------------- Commit messages: - Remove test dependencies on ReferenceQueue$Lock and Shutdown$Lock Changes: https://git.openjdk.org/jdk/pull/29455/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29455&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376533 Stats: 26 lines in 5 files changed: 6 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29455.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29455/head:pull/29455 PR: https://git.openjdk.org/jdk/pull/29455 From shade at openjdk.org Wed Jan 28 07:48:04 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 07:48:04 GMT Subject: Integrated: 8373266: Strengthen constant CardTable base accesses In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev wrote: > Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. > > Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. > > Shenandoah added a few asserts to catch these errors: > SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) > > ...but G1 would also benefit from the similar safety mechanism. > > This PR strengthens the code to prevent future accidents. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc` > - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z > - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z > - [x] GHA, cross-compilation only This pull request has now been integrated. Changeset: 88c8a55a Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763 Stats: 99 lines in 15 files changed: 35 ins; 25 del; 39 mod 8373266: Strengthen constant CardTable base accesses Reviewed-by: tschatzl, xpeng ------------- PR: https://git.openjdk.org/jdk/pull/28703 From shade at openjdk.org Wed Jan 28 07:48:03 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 07:48:03 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev wrote: >> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. >> >> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream. >> >> Shenandoah added a few asserts to catch these errors: >> SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) >> >> ...but G1 would also benefit from the similar safety mechanism. >> >> This PR strengthens the code to prevent future accidents. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc` >> - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z >> - [x] GHA, cross-compilation only > > Aleksey Shipilev 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: > > Some polishing Thanks folks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3809555279 From eirbjo at openjdk.org Wed Jan 28 08:41:20 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 08:41:20 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` Note that `ConcurrentAssociateTest` and `Phaser/Basic` additionally depends on the existence of the long gone class `java.lang.ref.Reference$Lock`. This class was removed by JDK-8156500 back in 2016, so these dump methods have been slightly "broken" in their filtering since then. This PR cleans up that as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29455#issuecomment-3809806810 From aartemov at openjdk.org Wed Jan 28 09:26:17 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 09:26:17 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: References: Message-ID: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8366659: Indentation fix. - 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/a3f07b94..6620a88f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=31-32 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Wed Jan 28 09:26:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 09:26:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 02:31:31 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewer's comment. > > src/hotspot/share/runtime/objectMonitor.cpp line 2244: > >> 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, >> 2243: "was not notified and is not in the right state: was_notified = %s, state = %s", >> 2244: was_notified ? "true" : "false", node->getTStateName(state)); > > Suggestion: > > assert(was_notified || state == ObjectWaiter::TS_RUN, > "was not notified and is not in the right state: was_notified = %s, state = %s", > was_notified ? "true" : "false", node->getTStateName(state)); > > Fix indent. > > Printing was_notified is redundant though as the assert can only fail if it is false. Thanks for spotting, addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2735645462 From kevinw at openjdk.org Wed Jan 28 09:35:11 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 28 Jan 2026 09:35:11 GMT Subject: RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v2] In-Reply-To: <79hDmxh1U08HsZCcmmVv8RgZm_CTAT-SdIpNVzYnAyE=.2ba9385a-d580-4fa3-ae3e-820daebb291a@github.com> References: <79hDmxh1U08HsZCcmmVv8RgZm_CTAT-SdIpNVzYnAyE=.2ba9385a-d580-4fa3-ae3e-820daebb291a@github.com> Message-ID: On Tue, 27 Jan 2026 22:05:14 GMT, Stuart Marks wrote: >> @thswlsqls Hi, are you able to edit the title of this PR to match the JBS issue? > > Note that the `\s` escape sequence denotes a SPACE character (U+0020) and not a BACKSPACE character as stated in the description. Thus the regex might actually match the relevant line in the example from @kevinjwalls' comment: > > # cat /proc/sys/kernel/core_pattern > |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F > > if the character following `-coredump` is a space character. > > Of course this is moot if the decision is to remove this stuff entirely... but it appears that the original code might have worked, at least in some cases. That might resolve the "How could this ever have worked?!?" mystery. Thanks @stuart-marks ! Yes of course. So the problem here is really coreadm not having permission to be useful when it's run, for most people. The split pattern was either an obscure choice at the time or a typo, but that part doesn't matter as much as this issue first suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3810083818 From jbhateja at openjdk.org Wed Jan 28 09:39:42 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:42 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v18] In-Reply-To: References: Message-ID: <23D_3Ap5t-E3oXX8yiulKT0bhbumyT4N8ucWDjNMZPE=.054aef2e-8280-448e-88b8-cbfcf91fbfaf@github.com> > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Adding new lane type constants for intrinsic entries, removing basictype extension changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/ce5768fa..68145fd9 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=16-17 Stats: 1162 lines in 58 files changed: 25 ins; 26 del; 1111 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Wed Jan 28 09:39:44 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:44 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz wrote: > > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3810098116 From sspitsyn at openjdk.org Wed Jan 28 11:34:24 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 11:34:24 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> References: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> Message-ID: On Wed, 28 Jan 2026 09:26:17 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8366659: Indentation fix. > - 8366659: Addressed reviewer's comments. Changes requested by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3716198918 From sspitsyn at openjdk.org Wed Jan 28 11:34:25 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 11:34:25 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> On Wed, 28 Jan 2026 02:27:10 GMT, David Holmes wrote: >>> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? >> >> It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: >> - suspend 1, resume 1, suspend 2 >> >> The `JvmtiExport::post_monitor_waited()` has a recursive call to `ThreadStateTransition::transition_from_native()` upon return from event callback. There is a suspend point there. >> I'll read it more carefully and provide update if needed. > > IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. The problem here is a decision to post the monitor waited event at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. One approach would be to refactor this as below: // Process suspend requests now if any, before posting the event { ThreadBlockInVM tbvm(current, true); } if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); Another approach would be to get rid of this `ThreadBlockInVM`. But it is hard to predict all the consequences. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736211365 From dholmes at openjdk.org Wed Jan 28 11:54:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 11:54:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> Message-ID: <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> On Wed, 28 Jan 2026 11:31:03 GMT, Serguei Spitsyn wrote: >> IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. > > Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. > As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. > The problem here is a decision to post the monitor waited event at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. > > One approach would be to refactor this as below: > > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > > Another approach would be to get rid of this `ThreadBlockInVM`. > But it is hard to predict all the consequences. The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736280646 From aartemov at openjdk.org Wed Jan 28 12:40:07 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 12:40:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 11:51:06 GMT, David Holmes wrote: >> Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. >> As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. >> The problem here is a decision to post the monitor waited event has been made at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. >> >> One approach would be to refactor this as below: >> >> // Process suspend requests now if any, before posting the event >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> >> Another approach would be to get rid of this `ThreadBlockInVM`. >> But it is hard to predict all the consequences. > > The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736447830 From rriggs at openjdk.org Wed Jan 28 13:56:21 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Jan 2026 13:56:21 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` The core-libs related changes look fine. So do the others but serviceability review would be good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29455#pullrequestreview-3716828194 From shade at openjdk.org Wed Jan 28 14:49:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 14:49:41 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` This looks fine to me. But yes, @plummercj or some other SA maintainer needs to confirm we are good there. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29455#pullrequestreview-3717115443 From sspitsyn at openjdk.org Wed Jan 28 16:03:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 16:03:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 12:37:55 GMT, Anton Artemov wrote: >> The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. > > Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. Okay. Then what about this ? : if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { // Process suspend requests now if any, before posting the event { ThreadBlockInVM tbvm(current, true); } if (JvmtiExport::should_post_monitor_waited()) { JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2737343109 From psandoz at openjdk.org Wed Jan 28 16:45:25 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 28 Jan 2026 16:45:25 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: <6-fyVKW-u3b6Bmm1FAhe7gMzlxOqr9wVwzk-FWXvR8s=.db3b9aa0-87f2-4861-b282-d198fc5ae543@github.com> On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Clanups >> - Refactoring vectorIntrinsics >> - Refactoring and cleanups >> - Refactoring and cleanups >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa > >> We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? > Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. Thanks, i think this is much better, more localized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3812429459 From cjplummer at openjdk.org Wed Jan 28 18:22:58 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Jan 2026 18:22:58 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga wrote: >> [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline. >> However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only. >> >> >> 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206 >> DW_CFA_nop >> DW_CFA_nop >> DW_CFA_nop >> >> >> Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java: >> >> >> 0x00007f14d500204d os::abort(bool, void const*, void const*) [clone .co >> ld] + 0x4 >> 0x00007f14d6bd0001 VMError::report_and_die(int, char const*, char const >> *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c >> onst*, int, unsigned long) + 0x6f1 >> 0x00007f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*, char const*, ...) + 0x88 >> 0x00007f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*) + 0x58 >> 0x00007f14d68ff1ba JVM_handle_linux_signal + 0x42a >> 0x00007f14d7964290 >> 0x00007f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash >> 0x00007f14be7468ba >> ----------System.err:(20/1429)---------- >> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring for simplifying src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 105: > 103: _return_address_reg = RA; > 104: _cfa_offset = 0; > 105: _ra_cfa_offset = 8; Can you explain where this offset of 8 is coming from. I see it used in a few places. src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 122: > 120: int rem_cfa_offset = 0; > 121: int rem_ra_cfa_offset = 8; > 122: int rem_bp_cfa_offset = INT_MAX; Although not introduced by this PR, I noticed the "remember state" code while reading through our existing sources and also reading up on the .eh_frame format. Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep. Is this something that should be eventually fixed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2737921950 PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2737858165 From sspitsyn at openjdk.org Wed Jan 28 18:40:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 18:40:01 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 15:59:58 GMT, Serguei Spitsyn wrote: >> Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. > > Okay. Then what about this ? : > > if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event. > // The monitor waited events can be disabled while suspended. > { > ThreadBlockInVM tbvm(current, true); > } > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Just want to explain my concern better. At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_RUN`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is a `ThreadBlockInVM` for this case, so the thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended. However the event will be posted after suspension. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2737985956 From cjplummer at openjdk.org Wed Jan 28 20:26:51 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Jan 2026 20:26:51 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 03:55:13 GMT, Yasumasa Suenaga wrote: > Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. > For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: > > > 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a > 0x00007faae4ad9290 > 0x00007faae4cd8e69 ???????? > 0x00007faaca78ffa1 > 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > It should be: > > > 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a > 0x00007fb584fd9290 > 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 > 0x00007fb56a78f321 > 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 702: > 700: if (strcmp("linux-vdso.so.1", lib_name) == 0 || > 701: strcmp("linux-vdso64.so.1", lib_name) == 0) { > 702: struct utsname uts; It might be more readable if all the new code below this point was in a new function, but I'll leave it up to you to decide if it is worth doing. src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 709: > 707: = "vdso64.so"; > 708: #else > 709: = "vdso32.so"; Do we need 32 bit support? I though it was already dropped. src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 712: > 710: #endif > 711: > 712: // Check vDSO binary at first (for referring debuginfo if possible). Suggestion: // Check vDSO binary first (for referring debuginfo if possible). src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 720: > 718: lib_fd = pathmap_open(lib_name); > 719: } else { > 720: // Copy vDSO memory segment to temporal memory from core Suggestion: // Copy vDSO memory segment from core to temporal memory ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2738464103 PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2738450779 PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2738471726 PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2738469538 From dholmes at openjdk.org Wed Jan 28 20:44:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 20:44:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn wrote: >> Okay. Then what about this ? : >> >> if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> // The monitor waited events can be disabled while suspended. >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (JvmtiExport::should_post_monitor_waited()) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Just want to explain my concern better. > At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. > If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_RUN`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. > If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > At the monitor notification point there is a check for JvmtiExport::should_post_monitor_waited(). > If it is false then the node.TState is set to ObjectWaiter::TS_RUN. > If it is true the node.TState is set to ObjectWaiter::TS_ENTER. @sspitsyn you have that the wrong way around. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738525236 From sspitsyn at openjdk.org Wed Jan 28 20:57:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 20:57:45 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn wrote: >> Okay. Then what about this ? : >> >> if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> // The monitor waited events can be disabled while suspended. >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (JvmtiExport::should_post_monitor_waited()) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Just want to explain my concern better. > At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. > If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. > If it is `true` the `node.TState` is set to `ObjectWaiter::TS_RUN`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > @sspitsyn you have that the wrong way around. Thanks! Corrected in place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738567428 From dholmes at openjdk.org Wed Jan 28 21:14:04 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 21:14:04 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 20:54:42 GMT, Serguei Spitsyn wrote: >> Just want to explain my concern better. >> At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. >> If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. >> If it is `true` the `node.TState` is set to `ObjectWaiter::TS_RUN`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > >> @sspitsyn you have that the wrong way around. > > Thanks! Corrected in place. Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738624642 From duke at openjdk.org Wed Jan 28 21:15:30 2026 From: duke at openjdk.org (Larry Cable) Date: Wed, 28 Jan 2026 21:15:30 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v13] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain. > > effectively: > > someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm() > > (where interim oops are null-checked) Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8327246: updated VM.classes 'help' description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/4b1bb228..369b8c02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=11-12 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048 PR: https://git.openjdk.org/jdk/pull/29048 From sspitsyn at openjdk.org Wed Jan 28 21:33:56 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 21:33:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:10:57 GMT, David Holmes wrote: > Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738696353 From pchilanomate at openjdk.org Wed Jan 28 22:13:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Jan 2026 22:13:24 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be Message-ID: Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/29473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376405 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29473/head:pull/29473 PR: https://git.openjdk.org/jdk/pull/29473 From ysuenaga at openjdk.org Thu Jan 29 00:06:52 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 00:06:52 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Wed, 28 Jan 2026 18:02:19 GMT, Chris Plummer wrote: > Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep. Yes. Remember states should be stacked, but I haven't seen that case. So I implemented to save (push) once so far. I can fix it, but I want to do it in subsequent PR (for AArch64) because I will update register offset handling for generalization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739142879 From ysuenaga at openjdk.org Thu Jan 29 00:14:08 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 00:14:08 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Wed, 28 Jan 2026 18:19:44 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring for simplifying > > src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 105: > >> 103: _return_address_reg = RA; >> 104: _cfa_offset = 0; >> 105: _ra_cfa_offset = 8; > > Can you explain where this offset of 8 is coming from. I see it used in a few places. It comes from RBP -8 (return address on stack). Return Address (RA) tends to be CFA - 8 because CFA tends to point RBP, and return address is RBP - 8 in that case. AFAICS return address would be defined in CFI (in CIE at least), thus we can set arbitraly value in initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739157882 From ysuenaga at openjdk.org Thu Jan 29 00:17:12 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 00:17:12 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v2] In-Reply-To: References: Message-ID: > Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. > For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: > > > 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a > 0x00007faae4ad9290 > 0x00007faae4cd8e69 ???????? > 0x00007faaca78ffa1 > 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > It should be: > > > 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a > 0x00007fb584fd9290 > 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 > 0x00007fb56a78f321 > 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Co-authored-by: Chris Plummer - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Co-authored-by: Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29400/files - new: https://git.openjdk.org/jdk/pull/29400/files/e27802e5..ecbc096e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29400&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29400&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29400/head:pull/29400 PR: https://git.openjdk.org/jdk/pull/29400 From dholmes at openjdk.org Thu Jan 29 00:22:01 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 00:22:01 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio So we are logically suspended (`is_suspended()` is true) but we haven't actually done a check for suspension that would cause us to actually block, due to the transition-disabler? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3814621640 From dholmes at openjdk.org Thu Jan 29 01:18:54 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 01:18:54 GMT Subject: RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread In-Reply-To: References: Message-ID: On Sat, 24 Jan 2026 08:37:21 GMT, Leonid Mesnik wrote: > The > > [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread > > disables posting ResourceExhausted events on CompilerThread because it can't post event. > The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading). > So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread. > > Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource. > > It is hard generate OOME in the CompilerThread to test this fix. > > The fix was tested by patch that generated event for codecache exchausting and new test. > https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1 @lmesnik exactly what kinds of "resource exhausted" events do you expect to encounter in a compiler thread? There are only 4 places I see them being posted. - The `JVM_StartThread` case is not applicable to compiler threads. - The main heap allocation site does: JvmtiExport::post_resource_exhausted( JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, message); but I don't believe you can post this from a compiler thread without needing to change the JVM TI specification. At the moment the spec states: > JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | 0x0001 | After this event returns, the VM will throw a java.lang.OutOfMemoryError. but if you change things so that a compiler thread now causes this to be posted on the service thread, then that is not true - there will not be an OOM in either thread. If the compiler thread itself hit this case it would not throw an OOM anyway. - The metaspace OOM would have the same problem - but I don't think the compiler thread could ever trigger that. - The post_array_size_exhausted is also I think, not applicable to the compiler thread So I am unclear exactly what problem is intended to be solved here - or how you can generally solve it given the specification for ` JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29397#issuecomment-3814794675 From ysuenaga at openjdk.org Thu Jan 29 01:28:02 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 01:28:02 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3] In-Reply-To: References: Message-ID: > Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. > For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: > > > 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a > 0x00007faae4ad9290 > 0x00007faae4cd8e69 ???????? > 0x00007faaca78ffa1 > 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > It should be: > > > 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 > 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a > 0x00007fb584fd9290 > 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 > 0x00007fb56a78f321 > 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) > > > Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision: - Add new function to handle vDSO - Remove unneeded change - Remove 32 bit support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29400/files - new: https://git.openjdk.org/jdk/pull/29400/files/ecbc096e..38daaa32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29400&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29400&range=01-02 Stats: 61 lines in 2 files changed: 32 ins; 28 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29400/head:pull/29400 PR: https://git.openjdk.org/jdk/pull/29400 From ysuenaga at openjdk.org Thu Jan 29 01:28:05 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 01:28:05 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:21:59 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add new function to handle vDSO >> - Remove unneeded change >> - Remove 32 bit support > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 702: > >> 700: if (strcmp("linux-vdso.so.1", lib_name) == 0 || >> 701: strcmp("linux-vdso64.so.1", lib_name) == 0) { >> 702: struct utsname uts; > > It might be more readable if all the new code below this point was in a new function, but I'll leave it up to you to decide if it is worth doing. Separated them as new function in new commit. > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 709: > >> 707: = "vdso64.so"; >> 708: #else >> 709: = "vdso32.so"; > > Do we need 32 bit support? I though it was already dropped. Removed it in new commit to support 64 bit only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2739339771 PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2739338255 From ysuenaga at openjdk.org Thu Jan 29 01:30:43 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 01:30:43 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3] In-Reply-To: References: Message-ID: <9adUuR2v9P0poMqAfK8G_ozLkW19AtrNO788SQelHY0=.c6f9ad8f-963b-434c-961d-3f204439abe8@github.com> On Thu, 29 Jan 2026 01:28:02 GMT, Yasumasa Suenaga wrote: >> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. >> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: >> >> >> 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a >> 0x00007faae4ad9290 >> 0x00007faae4cd8e69 ???????? >> 0x00007faaca78ffa1 >> 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> It should be: >> >> >> 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a >> 0x00007fb584fd9290 >> 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 >> 0x00007fb56a78f321 >> 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. > > Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision: > > - Add new function to handle vDSO > - Remove unneeded change > - Remove 32 bit support Thanks @plummercj for your comment! However I saw still a problem when kernel debuginfo is not installed on Fedora. It is same problem reported in [JDK-8376284](https://bugs.openjdk.org/browse/JDK-8376284). Maybe most of CI would fail due to TestJhsdbJstackMixedWithVDSOCallCore.java introduced in this PR... Should we remove TestJhsdbJstackMixedWithVDSOCallCore.java from this PR? or should we work JDK-8376284 first? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3814832539 From dholmes at openjdk.org Thu Jan 29 01:33:13 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 01:33:13 GMT Subject: RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread In-Reply-To: References: Message-ID: On Sat, 24 Jan 2026 08:37:21 GMT, Leonid Mesnik wrote: > The > > [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread > > disables posting ResourceExhausted events on CompilerThread because it can't post event. > The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading). > So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread. > > Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource. > > It is hard generate OOME in the CompilerThread to test this fix. > > The fix was tested by patch that generated event for codecache exchausting and new test. > https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1 In relation to the metaspace OOM the 2018 discussion (see JBS) indicates it is possible, but Thomas also notes: > If the JIT runs into metaspace OOM, it will cope by bailing out and leave that particular method uncompiled. I argue that this is not observable to the user and therefore ResourceExhausted can be suppressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29397#issuecomment-3814839347 From dholmes at openjdk.org Thu Jan 29 01:42:32 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 01:42:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:30:15 GMT, Serguei Spitsyn wrote: >> Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > >> Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > > Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. > Update: I see your point. You most likely suggested something like this: > > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > // Re-check the condition as the monitor waited events can be disabled whilst thread was suspended. > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Yes that is what I meant. The event could have been disabled since the notification, in which case we don't need to bother with the TBIVM etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2739379031 From cjplummer at openjdk.org Thu Jan 29 03:41:37 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Jan 2026 03:41:37 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 01:28:02 GMT, Yasumasa Suenaga wrote: >> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. >> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: >> >> >> 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a >> 0x00007faae4ad9290 >> 0x00007faae4cd8e69 ???????? >> 0x00007faaca78ffa1 >> 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> It should be: >> >> >> 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a >> 0x00007fb584fd9290 >> 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 >> 0x00007fb56a78f321 >> 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. > > Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision: > > - Add new function to handle vDSO > - Remove unneeded change > - Remove 32 bit support This PR needs a test so I would not suggest dropping TestJhsdbJstackMixedWithVDSOCallCore.java. Regarding our CI, we aren't seeing failures with serviceability/sa/TestJhsdbJstackMixedCore.java, but then our CI does not cover Alpine Linux or Fedora. However, it others do test these platforms and likely would not want to see another test failure introduced. I would suggest resolving [JDK-8376284](https://bugs.openjdk.org/browse/JDK-8376284) and apply the same fix here to TestJhsdbJstackMixedWithVDSOCallCore.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3815292161 From cjplummer at openjdk.org Thu Jan 29 03:45:55 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Jan 2026 03:45:55 GMT Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2] In-Reply-To: References: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com> Message-ID: On Thu, 29 Jan 2026 00:04:24 GMT, Yasumasa Suenaga wrote: >> src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 122: >> >>> 120: int rem_cfa_offset = 0; >>> 121: int rem_ra_cfa_offset = 8; >>> 122: int rem_bp_cfa_offset = INT_MAX; >> >> Although not introduced by this PR, I noticed the "remember state" code while reading through our existing sources and also reading up on the .eh_frame format. Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep. Is this something that should be eventually fixed? > >> Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep. > > Yes. > Remember states should be stacked, but I haven't seen that case. So I implemented to save (push) once so far. > I can fix it, but I want to do it in subsequent PR (for AArch64) because I will update register offset handling for generalization. Yes, a separate PR would be best. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739786274 From lmesnik at openjdk.org Thu Jan 29 05:02:24 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 Jan 2026 05:02:24 GMT Subject: RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 01:30:24 GMT, David Holmes wrote: >> The >> >> [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread >> >> disables posting ResourceExhausted events on CompilerThread because it can't post event. >> The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading). >> So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread. >> >> Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource. >> >> It is hard generate OOME in the CompilerThread to test this fix. >> >> The fix was tested by patch that generated event for codecache exchausting and new test. >> https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1 > > In relation to the metaspace OOM the 2018 discussion (see JBS) indicates it is possible, but Thomas also notes: >> If the JIT runs into metaspace OOM, it will cope by bailing out and leave that particular method uncompiled. I argue that this is not observable to the user and therefore ResourceExhausted can be suppressed. @dholmes-ora Thank you for a feedback. The goal was to call ResourceExhausted event when Compiler can't continue to work. The typical agent using ResourceExhausted usually kills application in this case, sometimes running some diagnostics. The spec says "Sent when a VM resource needed by a running application has been exhausted. Except as required by the optional capabilities, the set of resources which report exhaustion is implementation dependent." and I think that it makes sense to notify users in the case if any of resources are exhausted. However, I missed that this event should be posted on the thread that hit OOME. Also, I thought if hitting CodeCache full deserves ResourceExhausted. The inability to compile methods usually is a huge problem in the real applications. Tool like jvmquake might benefit from handling these events. Might be it would be better to add JVMTI_RESOURCE_EXHAUSTED_INTERNAL_VM that is triggered when VM is out of resources to continue to work normally. I'll discuss this with serviceability team and rethink solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29397#issuecomment-3815497650 From ysuenaga at openjdk.org Thu Jan 29 06:31:13 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 06:31:13 GMT Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 01:28:02 GMT, Yasumasa Suenaga wrote: >> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only. >> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following: >> >> >> 0x00007faae3dd0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007faae3aff1ba JVM_handle_linux_signal + 0x42a >> 0x00007faae4ad9290 >> 0x00007faae4cd8e69 ???????? >> 0x00007faaca78ffa1 >> 0x00007faaca73fd48 * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> It should be: >> >> >> 0x00007fb5841d0818 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58 >> 0x00007fb583eff1ba JVM_handle_linux_signal + 0x42a >> 0x00007fb584fd9290 >> 0x00007fb5851d8e69 __cvdso_gettimeofday_data.constprop.0 + 0x99 >> 0x00007fb56a78f321 >> 0x00007fb56a73fd48 * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame) >> >> >> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules//vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory. > > Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision: > > - Add new function to handle vDSO > - Remove unneeded change > - Remove 32 bit support I've created PR for [JDK-8376284](https://bugs.openjdk.org/browse/JDK-8376284) as #29480. I will update this PR after #29480 to check whether debuginfo for vDSO is available in TestJhsdbJstackMixedWithVDSOCallCore.java. (I want to back this to draft PR, but I couldn't...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3815740806 From sspitsyn at openjdk.org Thu Jan 29 08:28:47 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 08:28:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> References: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> Message-ID: On Wed, 28 Jan 2026 09:26:17 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8366659: Indentation fix. > - 8366659: Addressed reviewer's comments. I only have one minor change request. The fix looks good otherwise. Overall, it is a great work to sort this out. Thank you for your patience. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3721312113 From aartemov at openjdk.org Thu Jan 29 08:52:42 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 08:52:42 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in three places where the successor could be suspended: > > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Extra check before posting the waited event. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/6620a88f..c3f934b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=32-33 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Thu Jan 29 08:52:43 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 08:52:43 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:30:15 GMT, Serguei Spitsyn wrote: >> Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > >> Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > > Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. > Update: I see your point. You most likely suggested something like this: > > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > // Re-check the condition as the monitor waited events can be disabled whilst thread was suspended. > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Thanks @sspitsyn, I added that extra check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2740557790 From sspitsyn at openjdk.org Thu Jan 29 08:56:32 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 08:56:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3721429996 From sspitsyn at openjdk.org Thu Jan 29 09:23:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:23:41 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: some tweaks for carrier thread JvmtiThreadState initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29436/files - new: https://git.openjdk.org/jdk/pull/29436/files/4e3ff29a..23d6f88e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=00-01 Stats: 15 lines in 1 file changed: 9 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From sspitsyn at openjdk.org Thu Jan 29 09:23:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:23:43 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: On Wed, 28 Jan 2026 00:13:53 GMT, Alex Menkov wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 127: >> >>> 125: thread->set_interp_only_mode(false); >>> 126: } >>> 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> >> wouldn't be better to move this into the beginning of ctor: >> >> if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> _thread = thread; >> _thread_saved = nullptr; >> } else { >> _thread_saved = thread; >> _thread = nullptr; >> } >> >> and might be add comments with explanation. > > +1 > And have you tried to implement a test for the case? > wouldn't be better to move this into the beginning of ctor Good suggestion, thanks. Fixed now and added a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2740677522 From sspitsyn at openjdk.org Thu Jan 29 09:27:57 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:27:57 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: <7UKo8YzijAm9n3S5ePQjJbIR9E8Z7cQfmpLSHwcBe_w=.6cce24e2-294a-4b67-86d5-acf698c32213@github.com> On Thu, 29 Jan 2026 09:18:37 GMT, Serguei Spitsyn wrote: >> +1 >> And have you tried to implement a test for the case? > >> wouldn't be better to move this into the beginning of ctor > > Good suggestion, thanks. Fixed now and added a comment. > And have you tried to implement a test for the case? This issue was discovered in a branch with another PR as it has an optimized implementation for the `FramePop` events. Some of the existing tests were failing intermittently. Now, I do not remember the exact failing tests. In fact, it is not easy to provide a test coverage for this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2740700582 From stuefe at openjdk.org Thu Jan 29 09:39:25 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:39:25 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Fri, 23 Jan 2026 14:59:45 GMT, Ivan Bereziuk wrote: > The timestamping implemented in JCmd.java would print timestamp only once at the beginning. Good point. For me the biggest point would be to cleanly correlate time in logs, e.g. gc logs, with time from command invocations the analyst or customer does. Without wondering about offsets. > We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. Also good point. I know I am of no help here :-D My gut instinct is to keep jcmd client side simple and stupid, and put logic like this into hotspot. But I can live with both solutions. Having a timestamp always printed will be a good thing in any case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3816525840 From stuefe at openjdk.org Thu Jan 29 09:50:30 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:50:30 GMT Subject: RFR: 8359706: Add file descriptor count to VM.info [v8] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell wrote: >> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms. >> >> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > minor updates Sorry for the long delay. Can you please add some jtreg test for this? The simplest way would be to extend test/jdk/sun/tools/jcmd/TestJcmdSanity.java. See testJcmdPidVMinfo. Please test that the output shows the parameter "END." at the end (indicating that the printout did not time out). And please test, on Mac and Linux, that we see "Open File Descriptors: \\d+". (you can just use Platform.isxxx to exclude other platforms). Thanks! src/hotspot/os/bsd/os_bsd.cpp line 2617: > 2615: st->print_cr("Open File Descriptors: unknown"); > 2616: #endif > 2617: } stray newline src/hotspot/os/linux/os_linux.cpp line 5412: > 5410: timed_out = true; > 5411: break; > 5412: } Can you please do a little manual test like this: if (fds > some number) sleep(Timeout * 2); and check if the timeout works? ------------- PR Review: https://git.openjdk.org/jdk/pull/27971#pullrequestreview-3721621599 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2740752734 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2740765861 From dholmes at openjdk.org Thu Jan 29 12:03:31 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 12:03:31 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. I think that is everything from me. Thanks. It has been a very tricky one to work through. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3722268994 From lmesnik at openjdk.org Thu Jan 29 15:39:48 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 Jan 2026 15:39:48 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization Thanks for updating. Fix looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29436#pullrequestreview-3723483018 From sspitsyn at openjdk.org Thu Jan 29 15:52:06 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 15:52:06 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio Looks good. Strangely, I did not see this assert in my testing when the ThreadStateTest2 test was introduced. :) ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3723550698 From sspitsyn at openjdk.org Thu Jan 29 15:55:19 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 15:55:19 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29436#issuecomment-3818555405 From dcubed at openjdk.org Thu Jan 29 17:46:22 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 29 Jan 2026 17:46:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Re-reviewed v33. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3724159576 From dcubed at openjdk.org Thu Jan 29 17:46:24 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 29 Jan 2026 17:46:24 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v9] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 21:50:07 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1950: >> >>> 1948: // as having "-locked" the monitor, but the OS and java.lang.Thread >>> 1949: // states will still report that the thread is blocked trying to >>> 1950: // acquire it. >> >> Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). @dcubed-ojdk, could you comment on this, please? > > Sorry for the long delay in getting back to this review. > > Hmmmm... I'm wondering if that comment is correct: > - We've creat `ExitOnSuspend eos` on L1961. > - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`. > - We reenter the monitor on L1964. > - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below: > - We call the `eos` object on the current thread BEFORE we `call process_if_requested` > > So it looks to me like we exit the monitor before we block for the safepoint so we should not > be showing the monitor as "locked" by our "blocked" thread. I think the comment addition on L1974-1976 addresses this review thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2742799060 From aturbanov at openjdk.org Thu Jan 29 18:06:20 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 29 Jan 2026 18:06:20 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapCacheEntry.java line 99: > 97: Method method() { return method; } > 98: int bci() { return bci; } > 99: public int numberOfEntries() { return maskSize; } Suggestion: public int numberOfEntries() { return maskSize; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29058#discussion_r2742874729 From ysuenaga at openjdk.org Thu Jan 29 18:06:18 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 18:06:18 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year in ConstantPool.java > - Update ClhsdbDumpheap to verify HPROF_GC_ROOT_JAVA_FRAME PING: can I get second reviewer? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3808863131 From pchilanomate at openjdk.org Thu Jan 29 18:35:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 18:35:24 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 00:19:05 GMT, David Holmes wrote: > So we are logically suspended (`is_suspended()` is true) but we haven't actually done a check for suspension that would cause us to actually block, due to the transition-disabler? > Exactly. Suspending inside a `MountUnmountDisabler` scope would lead to a deadlock since the resumer won't be able to run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3819515604 From pchilanomate at openjdk.org Thu Jan 29 18:35:27 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 18:35:27 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: <_OP5TGNtsbOYEF8gDLDTV_0qDnvNZUtLWB9jE0cYkyA=.a97957ff-8c49-4bd9-a4fa-09e800918443@github.com> On Thu, 29 Jan 2026 15:48:50 GMT, Serguei Spitsyn wrote: > Looks good. Strangely, I did not see this assert in my testing when the ThreadStateTest2 test was introduced. :) > Makes sense because it's intermittent. I'm able to reproduce it by running the test in a loop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3819521683 From ysuenaga at openjdk.org Thu Jan 29 23:41:33 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 29 Jan 2026 23:41:33 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v3] In-Reply-To: References: Message-ID: > We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. > > I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: > > > -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError > > > heapdumponoutofmemoryerror > > This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. > > from-core > > On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. > > heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. > > Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . > > This change works fine with both interpreter and `-Xcomp`. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapCacheEntry.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29058/files - new: https://git.openjdk.org/jdk/pull/29058/files/12bb02db..a5e2753c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29058&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29058&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29058/head:pull/29058 PR: https://git.openjdk.org/jdk/pull/29058 From dholmes at openjdk.org Fri Jan 30 00:00:52 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:00:52 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization src/hotspot/share/prims/jvmtiThreadState.cpp line 61: > 59: > 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > 61: // Carrier and virtual threads can temporary share the same JavaThread. Suggestion: // Carrier and virtual threads can temporarily share the same JavaThread. src/hotspot/share/prims/jvmtiThreadState.cpp line 65: > 63: // It is needed for interp-only mechanism. > 64: _thread = nullptr; > 65: _thread_saved = thread; The meaning of these variables is not described here or in the header file. That makes it hard to assess the correctness based on the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744014657 PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744018321 From dholmes at openjdk.org Fri Jan 30 00:00:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:00:53 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: On Thu, 29 Jan 2026 23:56:32 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: some tweaks for carrier thread JvmtiThreadState initialization > > src/hotspot/share/prims/jvmtiThreadState.cpp line 61: > >> 59: >> 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> 61: // Carrier and virtual threads can temporary share the same JavaThread. > > Suggestion: > > // Carrier and virtual threads can temporarily share the same JavaThread. Also I think this comment block should come before the if statement as it seems to be explaining both the if and else cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744016478 From dholmes at openjdk.org Fri Jan 30 04:39:23 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:39:23 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio Seems reasonable. One suggestion that may not be worthwhile so feel free to ignore. Thanks src/hotspot/share/runtime/continuation.cpp line 92: > 90: assert(!_current->is_suspended() || > 91: (_current->is_vthread_transition_disabler() && _result != freeze_ok), "must be"); > 92: #endif Suggestion: assert(!_current->is_suspended() JVMTI_ONLY(|| (_current->is_vthread_transition_disabler() && _result != freeze_ok)) , "must be"); Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ?? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3726282698 PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2744568340 From sspitsyn at openjdk.org Fri Jan 30 07:10:27 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:10:27 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 04:36:21 GMT, David Holmes wrote: > Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ?? Good suggestion. JVMTI is the only way to suspend threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2744955251 From sspitsyn at openjdk.org Fri Jan 30 07:45:04 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:04 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v3] In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: moved and extended comment in JvmtiThreadState ctor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29436/files - new: https://git.openjdk.org/jdk/pull/29436/files/23d6f88e..e5735668 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=01-02 Stats: 10 lines in 1 file changed: 7 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From sspitsyn at openjdk.org Fri Jan 30 07:45:07 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:07 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: <898pyR61j5geo_EGN0nEeNSkP0Bn5e7Wu5BH-MqxG9k=.1786e7b6-fa1a-4eff-9b1a-8cfe439a35f1@github.com> On Thu, 29 Jan 2026 23:57:26 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 61: >> >>> 59: >>> 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >>> 61: // Carrier and virtual threads can temporary share the same JavaThread. >> >> Suggestion: >> >> // Carrier and virtual threads can temporarily share the same JavaThread. > > Also I think this comment block should come before the if statement as it seems to be explaining both the if and else cases. Thank you for suggestions. Moved and extended the comment to make it more understandable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2745036660 From sspitsyn at openjdk.org Fri Jan 30 07:45:11 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:11 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: On Thu, 29 Jan 2026 23:58:16 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: some tweaks for carrier thread JvmtiThreadState initialization > > src/hotspot/share/prims/jvmtiThreadState.cpp line 65: > >> 63: // It is needed for interp-only mechanism. >> 64: _thread = nullptr; >> 65: _thread_saved = thread; > > The meaning of these variables is not described here or in the header file. That makes it hard to assess the correctness based on the comments. Thanks. Addressed. Please, see above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2745038193 From sspitsyn at openjdk.org Fri Jan 30 08:27:26 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 08:27:26 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 14:56:31 GMT, Jean-Philippe Bempel wrote: >> ?retransformed >> >> Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. >> >> Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > add copyright headers src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > 1475: if (res != JVMTI_ERROR_NONE) { > 1476: return res; > 1477: } Pending exception need to be processed and cleared below (see lines: 1478-1487). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745165920 From jpbempel at openjdk.org Fri Jan 30 09:09:58 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Fri, 30 Jan 2026 09:09:58 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 08:24:22 GMT, Serguei Spitsyn wrote: >> Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: >> >> add copyright headers > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > >> 1475: if (res != JVMTI_ERROR_NONE) { >> 1476: return res; >> 1477: } > > Pending exception need to be processed and cleared below (see lines: 1478-1487). @sspitsyn I am not sure to follow your comment. In the case of invalid structure, no exception was pending and therefore the method `load_new_class_versions` returns no error. if `merge_cp_and_rewrite` returns anything else than `JVMTI_ERROR_NONE` it should be propagated. Now, if you want to process pending exception first I can move the check result after, but for example the call above to `compare_and_normalize_class_versions` is done like this also ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745309806 From aartemov at openjdk.org Fri Jan 30 09:24:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 30 Jan 2026 09:24:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. >> >> This can happen in three places where the successor could be suspended: >> >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Thank you all for reviews. I am going to integrate it in the beginning of the next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3822699886 From ysuenaga at openjdk.org Fri Jan 30 12:12:27 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 30 Jan 2026 12:12:27 GMT Subject: RFR: 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine Message-ID: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following: java.lang.RuntimeException: '' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62) at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1516) It would success if debuginfo is installed, but it should be skipped if the symbol is not available. See JBS for details. ------------- Commit messages: - 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine Changes: https://git.openjdk.org/jdk/pull/29480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376284 Stats: 122 lines in 2 files changed: 120 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29480/head:pull/29480 PR: https://git.openjdk.org/jdk/pull/29480 From duke at openjdk.org Fri Jan 30 13:05:21 2026 From: duke at openjdk.org (duke) Date: Fri, 30 Jan 2026 13:05:21 GMT Subject: Withdrawn: 8371380: [LOOM] The debug agent should avoid enabling VIRTUAL_THREAD_START/END events when possible In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 02:25:02 GMT, Chris Plummer wrote: > Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment. > > With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger. > > Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28485 From cjplummer at openjdk.org Fri Jan 30 22:11:04 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 30 Jan 2026 22:11:04 GMT Subject: RFR: 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine In-Reply-To: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> Message-ID: On Thu, 29 Jan 2026 06:20:57 GMT, Yasumasa Suenaga wrote: > TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following: > > > java.lang.RuntimeException: '' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62) > at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would success if debuginfo is installed, but it should be skipped if the symbol is not available. > See JBS for details. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 71: > 69: // Check whether the symbol of signal trampoline is available. > 70: var libc = SATestUtils.getLibCPath(); > 71: if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) { Do we have any reason to support the lookup of symbols not in libc? I'm just wondering if `SATestUtils.isSymbolAvailable()` should just take the symbol argument not the libc argument. test/lib/jdk/test/lib/SA/SATestUtils.java line 272: > 270: /** > 271: * Find library file what provides address of strlen(3), then returns it as libc. > 272: * This method would work on Linux only. Suggestion: * Find library file that provides strlen(3), then returns it as libc. * This method works on Linux only. test/lib/jdk/test/lib/SA/SATestUtils.java line 300: > 298: var info = arena.allocate(structDLInfo); > 299: int result = (int)dladdr.invoke(ptrStrlen, info); > 300: if(result == 0){ Suggestion: if (result == 0) { test/lib/jdk/test/lib/SA/SATestUtils.java line 315: > 313: /** > 314: * Find debuginfo file from the library. > 315: * This method would work on Linux only. Suggestion: * Find debuginfo file for the library. * This method will work on Linux only. test/lib/jdk/test/lib/SA/SATestUtils.java line 345: > 343: } > 344: > 345: private static boolean isSymbolAvailableInternal(String lib, String symbol) throws IOException { Should `lib` be named something more like `debugInfoPath`? test/lib/jdk/test/lib/SA/SATestUtils.java line 354: > 352: > 353: /** > 354: * This method would work on Linux only. Suggestion: * This method will work on Linux only. test/lib/jdk/test/lib/SA/SATestUtils.java line 356: > 354: * This method would work on Linux only. > 355: * Both "readelf" and "nm" have to be available. > 356: * @return true if given symbol is available on given lib. Suggestion: * @return true if given symbol is available in given lib. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748141842 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748107517 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748164779 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748145164 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748160452 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748135231 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748143118 From cjplummer at openjdk.org Fri Jan 30 22:12:54 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 30 Jan 2026 22:12:54 GMT Subject: RFR: 8374577: Heap dump from core does not contain HPROF_GC_ROOT_JAVA_FRAME [v3] In-Reply-To: References: Message-ID: <4uZzmdgLdZkAjwV5VOSxz9MvMyrh3UF4QNy9-1p8aNs=.2de2576b-89a6-47bf-828d-945f7bf2448f@github.com> On Thu, 29 Jan 2026 23:41:33 GMT, Yasumasa Suenaga wrote: >> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack. >> >> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options: >> >> >> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError >> >> >> heapdumponoutofmemoryerror >> >> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap. >> >> from-core >> >> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects. >> >> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that. >> >> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d . >> >> This change works fine with both interpreter and `-Xcomp`. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapCacheEntry.java > > Co-authored-by: Andrey Turbanov Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29058#pullrequestreview-3730631881 From ysuenaga at openjdk.org Sat Jan 31 01:07:25 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 31 Jan 2026 01:07:25 GMT Subject: RFR: 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine [v2] In-Reply-To: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> Message-ID: > TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following: > > > java.lang.RuntimeException: '' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62) > at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would success if debuginfo is installed, but it should be skipped if the symbol is not available. > See JBS for details. Yasumasa Suenaga has updated the pull request incrementally with five additional commits since the last revision: - Update test/lib/jdk/test/lib/SA/SATestUtils.java Co-authored-by: Chris Plummer - Update test/lib/jdk/test/lib/SA/SATestUtils.java Co-authored-by: Chris Plummer - Update test/lib/jdk/test/lib/SA/SATestUtils.java Co-authored-by: Chris Plummer - Update test/lib/jdk/test/lib/SA/SATestUtils.java Co-authored-by: Chris Plummer - Update test/lib/jdk/test/lib/SA/SATestUtils.java Co-authored-by: Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29480/files - new: https://git.openjdk.org/jdk/pull/29480/files/0fee6ce3..77d07827 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29480&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29480&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29480/head:pull/29480 PR: https://git.openjdk.org/jdk/pull/29480 From ysuenaga at openjdk.org Sat Jan 31 01:15:57 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 31 Jan 2026 01:15:57 GMT Subject: RFR: 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine [v3] In-Reply-To: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> Message-ID: > TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following: > > > java.lang.RuntimeException: '' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62) > at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would success if debuginfo is installed, but it should be skipped if the symbol is not available. > See JBS for details. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Clarify comments regarding debuginfo retrieval ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29480/files - new: https://git.openjdk.org/jdk/pull/29480/files/77d07827..1913d6bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29480&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29480&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29480/head:pull/29480 PR: https://git.openjdk.org/jdk/pull/29480 From ysuenaga at openjdk.org Sat Jan 31 01:15:59 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 31 Jan 2026 01:15:59 GMT Subject: RFR: 8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine [v3] In-Reply-To: References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com> Message-ID: On Fri, 30 Jan 2026 22:01:03 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify comments regarding debuginfo retrieval > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 71: > >> 69: // Check whether the symbol of signal trampoline is available. >> 70: var libc = SATestUtils.getLibCPath(); >> 71: if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) { > > Do we have any reason to support the lookup of symbols not in libc? I'm just wondering if `SATestUtils.isSymbolAvailable()` should just take the symbol argument not the libc argument. I want to use `isSymbolAvailable()` in JDK-8376269 (PR #29400) to find the symbol relates to `gettimeofday()` in vDSO. (so I defined `getDebugInfo(()` as public to check vDSO debuginfo availability) > test/lib/jdk/test/lib/SA/SATestUtils.java line 345: > >> 343: } >> 344: >> 345: private static boolean isSymbolAvailableInternal(String lib, String symbol) throws IOException { > > Should `lib` be named something more like `debugInfoPath`? This function is used for finding symbol from lib (not debuginfo) in L361. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748623694 PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2748624984 From acobbs at openjdk.org Sat Jan 31 20:03:49 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 31 Jan 2026 20:03:49 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v7] In-Reply-To: References: Message-ID: <3VvHHah7TVMP4_puXRq4urxiwR8UMSJugMQ3yQZdPJo=.cae130ee-beb0-448f-87f6-a3772894f618@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 140 commits: - Merge branch 'master' into JDK-8344159 to fix conflicts. - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - ... and 130 more: https://git.openjdk.org/jdk/compare/6ce2f3e1...ab9af044 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=06 Stats: 1696 lines in 35 files changed: 1494 ins; 49 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167