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: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
Message-ID: <Ky6ElI3CNfPPl0tq4DkXFZeMFDRQSkWMkYBHFMhVN_g=.61363193-699c-4b30-89b7-9e1c9813ef5f@github.com>

On Sat, 27 Dec 2025 09:55:58 GMT, Eunbin Son <duke at openjdk.org> wrote:

> ### Summary
> Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".
> 
> ### Description
> Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".
> 
> ### Bug ID : JDK-8374373
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373

This pull request has now been integrated.

Changeset: 752f46d6
Author:    Eunbin Son <thswlsqls at naver.com>
Committer: Alan Bateman <alanb at openjdk.org>
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: <raBeTodEerDMJRLWrBLiyNCSPp-EnUdRNa1spfIHM7c=.04366a92-6294-4821-84d2-f865da770ec0@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <raBeTodEerDMJRLWrBLiyNCSPp-EnUdRNa1spfIHM7c=.04366a92-6294-4821-84d2-f865da770ec0@github.com>
Message-ID: <3I1JkYgdEAbWKlIXLRp06aicDkVTTS7WXEzBHCvJAwA=.d32d6420-ec94-4960-90f2-8412a81d0ab7@github.com>

On Tue, 30 Dec 2025 23:20:34 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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("<COMPILED_METHOD_LOAD>:   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: <dYqSZwnLj2EXNKrVEjVB8JXdnzYyWMButTkfouxLmno=.b67a3ca9-06c0-402e-9e95-a288993adda3@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>
 <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com>
 <dYqSZwnLj2EXNKrVEjVB8JXdnzYyWMButTkfouxLmno=.b67a3ca9-06c0-402e-9e95-a288993adda3@github.com>
Message-ID: <whSRtVfkf4hk3glb4LqKBQ8yq9vsbU19vK6fm0lum3s=.3320dcb5-511b-40d5-9515-89fadfef1c36@github.com>

On Tue, 30 Dec 2025 23:17:20 GMT, Chad Rakoczy <duke at openjdk.org> 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: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>

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: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> 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: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <BAMcOdA9YtfhsDCtVdb_aqMPKIIchvIBv87vlB4hMvQ=.6125fe52-cbc5-4ab3-aade-b99799645e12@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> 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: <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
 <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>
Message-ID: <F8uiQNsC1WCZs4yLcNRgkFOyeK1N14DsCxSOBodJljE=.00ec8f1d-c355-4900-8ae5-89a76159f0a3@github.com>

On Fri, 2 Jan 2026 12:23:48 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <d7FYDYNSYPS6okNJhaH7YUEcB3D-l2bAQVYSQ7gnUYY=.09138388-8a4d-47b6-adca-a11013e72126@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> 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 <fandreuzzi at openjdk.org>
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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@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.

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

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: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@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 <StubRoutines>
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 <signal handler called>
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: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>

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: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>
Message-ID: <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>

On Mon, 10 Nov 2025 22:24:52 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <-sYToet_Qr8ddZAeRXW_5HoEJqfwCYNcWm0myfHVO-w=.a4955764-1b19-450c-b1cd-ca71d74376d0@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
Message-ID: <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@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 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: <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>
 <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>
Message-ID: <f6pcsITsjd2XSY-8XtQGxc4NraFT4zkL8qsXsPIx5XA=.d6f03fc4-fb53-4e4d-95d5-a47a8d41f4f4@github.com>

On Sun, 4 Jan 2026 02:17:35 GMT, Sergey Bylokhov <serb at openjdk.org> 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: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
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: <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
Message-ID: <d8LzVVlzwjySWH-mD-Z2s-jCMadLgV_klzKd1vWl3wQ=.dcaef134-c2ed-427a-bfba-7db30b9a9643@github.com>

On Fri, 19 Dec 2025 14:47:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve exception

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: <iUpE9FJmiHV0ngFYLwUiNBjEHwSmD2REvMGoOYoH6ZY=.c0069613-6fd9-4502-bd4a-49195e77c327@github.com>
References: <iUpE9FJmiHV0ngFYLwUiNBjEHwSmD2REvMGoOYoH6ZY=.c0069613-6fd9-4502-bd4a-49195e77c327@github.com>
Message-ID: <scpYvUoWTmUwbEMbhtANrakjGmz2LJlSgtDiOPBWBoc=.172fedf9-de57-4f16-bac2-743bfe635adb@github.com>

On Mon, 8 Dec 2025 09:23:32 GMT, SendaoYan <syan at openjdk.org> 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: <gw2gtAhas3Woau2rBJIBFjawQ5_-GOVGvMs2hbpXay4=.511cd1f1-5fd7-44e7-a291-1c2cf4b59c3d@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

This pull request has now been integrated.

Changeset: fa8ea6b3
Author:    Alex Menkov <amenkov at openjdk.org>
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: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.

Chad Rakoczy has updated the pull request incrementally with 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: <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> 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: <whSRtVfkf4hk3glb4LqKBQ8yq9vsbU19vK6fm0lum3s=.3320dcb5-511b-40d5-9515-89fadfef1c36@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <mnXolyftA_PzaWRx8HYfxXQbyT24BKqGXJFASWWLFPI=.f8261ae3-7050-4dd4-ad9a-53f279e2cba3@github.com>
 <3BKMnkjGqFppwUIql9uHwQyWYaveQ6nARCCJK4xc2_M=.c22e6f66-fa6d-4b05-9266-d7143a9262a3@github.com>
 <dYqSZwnLj2EXNKrVEjVB8JXdnzYyWMButTkfouxLmno=.b67a3ca9-06c0-402e-9e95-a288993adda3@github.com>
 <whSRtVfkf4hk3glb4LqKBQ8yq9vsbU19vK6fm0lum3s=.3320dcb5-511b-40d5-9515-89fadfef1c36@github.com>
Message-ID: <Fqy-0TaiTPu6LLy396BFALKhWoYCtLO-5p0tg440hpY=.e49671f1-5079-479f-bc64-6c0df3d9ed9f@github.com>

On Thu, 1 Jan 2026 19:54:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <IA1PR10MB6687218A5036487ADD6BF1E78D86A@IA1PR10MB6687.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260105/e9a4f153/attachment.htm>

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: <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> 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: <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
Message-ID: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>

On Mon, 5 Jan 2026 21:09:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <IA1PR10MB668781B491397DFC308C46198D86A@IA1PR10MB6687.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260105/2a540967/attachment.htm>

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: <IA1PR10MB6687846348C16A9839094D308D86A@IA1PR10MB6687.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260105/28b4947a/attachment-0001.htm>

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: <IA1PR10MB66878BA3334CC56AA29B243E8D86A@IA1PR10MB6687.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260105/00812789/attachment.htm>

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: <IA1PR10MB6687E8582EB1C2E8AC05CB998D86A@IA1PR10MB6687.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260105/812203f3/attachment.htm>

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: <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>
Message-ID: <WLpXc0Vq1xhsQeFgctQG4qaCRl76L_Wn86gMWsR72gU=.e5989b2b-13d3-48cd-8a83-1c5bf1be90c8@github.com>

On Mon, 5 Jan 2026 21:11:00 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 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<bool> 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: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
Message-ID: <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>

On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable <duke at openjdk.org> 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: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

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: <JZ1XBqTKrhaFobCXf5S-S_Y5ecvQYEHsd_1iK0GhtdI=.07f6f29a-b45f-4b9d-aba9-1566540b30d0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <JZ1XBqTKrhaFobCXf5S-S_Y5ecvQYEHsd_1iK0GhtdI=.07f6f29a-b45f-4b9d-aba9-1566540b30d0@github.com>
Message-ID: <NemuC0tOWZXYgr5dwa6biuw1zwgNOzU0RhC2bJ2WjFc=.6a90ab36-0bb0-4b43-bb45-e3f62fbc65a6@github.com>

On Mon, 29 Dec 2025 08:48:15 GMT, SendaoYan <syan at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <wi6xlCcCFypnMLIjqZWlS7poY5mX9ZNSblYMEDttZuM=.f8e642fb-f99a-4eca-9046-90928095391a@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>
Message-ID: <4cRjZst7BQ0wbyNLad-qy72Qn2qIGC2lNpFdQff2vHs=.29597aa7-c41d-49e4-919c-9d2a4bec6274@github.com>

On Mon, 5 Jan 2026 21:11:00 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 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: <WLpXc0Vq1xhsQeFgctQG4qaCRl76L_Wn86gMWsR72gU=.e5989b2b-13d3-48cd-8a83-1c5bf1be90c8@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <KBG7Gm94Kwuz7ncti-IsS5sGtzyYxJL1RezKLY4A6JM=.3059df8e-d3a6-49d8-b86d-d02e5f837100@github.com>
 <WLpXc0Vq1xhsQeFgctQG4qaCRl76L_Wn86gMWsR72gU=.e5989b2b-13d3-48cd-8a83-1c5bf1be90c8@github.com>
Message-ID: <vSa9vAc-Wrqr-HdgmU-k--YNOroQN777cH9vt6y7HS0=.9cba4391-2ba7-4cfe-b853-0d765019ed6b@github.com>

On Tue, 6 Jan 2026 00:18:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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<bool> 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: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <PsM7ISpFzgPWAi_0Dc-BYz0OnW5rgU3Rw9s6cy3EUIA=.78b56501-cdef-41a0-8971-9865e9e86898@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests.
> 
> Change has been verified locally. Test-fix only, no risk.

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

  Update 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: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <p0CopD3rLt7Zsf3vrnPHGAMbniMIXXjD92oOmf13Bbw=.e18c6b50-0e64-4f04-a0ff-3f14caff8c1f@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <NemuC0tOWZXYgr5dwa6biuw1zwgNOzU0RhC2bJ2WjFc=.6a90ab36-0bb0-4b43-bb45-e3f62fbc65a6@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <JZ1XBqTKrhaFobCXf5S-S_Y5ecvQYEHsd_1iK0GhtdI=.07f6f29a-b45f-4b9d-aba9-1566540b30d0@github.com>
 <NemuC0tOWZXYgr5dwa6biuw1zwgNOzU0RhC2bJ2WjFc=.6a90ab36-0bb0-4b43-bb45-e3f62fbc65a6@github.com>
Message-ID: <5qxuuuhHvgrHEPlLUV-O8Ngykq5lufQ5n_IbmXxeu0k=.65dc5916-245b-412b-a60f-1c0058464051@github.com>

On Tue, 6 Jan 2026 02:19:32 GMT, David Holmes <dholmes at openjdk.org> 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: <NemuC0tOWZXYgr5dwa6biuw1zwgNOzU0RhC2bJ2WjFc=.6a90ab36-0bb0-4b43-bb45-e3f62fbc65a6@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
 <JZ1XBqTKrhaFobCXf5S-S_Y5ecvQYEHsd_1iK0GhtdI=.07f6f29a-b45f-4b9d-aba9-1566540b30d0@github.com>
 <NemuC0tOWZXYgr5dwa6biuw1zwgNOzU0RhC2bJ2WjFc=.6a90ab36-0bb0-4b43-bb45-e3f62fbc65a6@github.com>
Message-ID: <t-9Urd5Xf8H7AfQxIbuQjw1BT_j-xyrDPwfsTImgqs8=.d51b15c6-9a63-4bec-8277-f1872b8a77a0@github.com>

On Tue, 6 Jan 2026 02:21:44 GMT, David Holmes <dholmes at openjdk.org> 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: <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
 <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>
Message-ID: <QCHJmyYi0RYzAbZPkhJ7FKIkS3-D-rDjKOukSRK-9_s=.d4feddb2-efef-48e6-a471-54aaaa8cd470@github.com>

On Tue, 6 Jan 2026 00:49:14 GMT, David Holmes <dholmes at openjdk.org> 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: <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> 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: <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> 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: <pklMzpwxKW6M71-RO15sUlE3Z-4r5n16H80mCBFAhb0=.8c6a88ee-ba99-46ac-9a5e-78ca28fb38b2@github.com>
References: <u_GiuOMAm4OkmaSJlZkN1DVJjdXwSlJywXrd9hYEr20=.5e4ae9fe-0ca1-4d21-8b82-1bb671699a6f@github.com>
 <pklMzpwxKW6M71-RO15sUlE3Z-4r5n16H80mCBFAhb0=.8c6a88ee-ba99-46ac-9a5e-78ca28fb38b2@github.com>
Message-ID: <kDgVlGoWDvjGoBzjkK8BgxoRFhFVaybDVaLNkB3s0nE=.a7ff9dd6-2a5b-422d-9da7-067fbb1d9cf4@github.com>

On Wed, 31 Dec 2025 09:38:10 GMT, Eunbin Son <duke at openjdk.org> wrote:

>> ### Summary
>> MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)".
>> 
>> This addresses the first of three issues in JDK-8374395.
>> 
>> ### Description
>> When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this.
>> 
>> toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged.
>> 
>> Added test cases to the existing jtreg test file. All tests pass.
>> 
>> ### Bug-ID : JDK-8374395 
>> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395
>
> 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: <wi6xlCcCFypnMLIjqZWlS7poY5mX9ZNSblYMEDttZuM=.f8e642fb-f99a-4eca-9046-90928095391a@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <wi6xlCcCFypnMLIjqZWlS7poY5mX9ZNSblYMEDttZuM=.f8e642fb-f99a-4eca-9046-90928095391a@github.com>
Message-ID: <dkPvsnUB0xdqA9vzdMw_OWw-QhOx50ZRUs5nPctEeMA=.3f0b5302-3226-4c92-be83-c2d25e56e954@github.com>

On Tue, 6 Jan 2026 02:39:08 GMT, David Holmes <dholmes at openjdk.org> 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: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <lV9DEcbBBZUpkEXYG7HFScuhBw3YlPwfP7AOeVFTHE4=.57008309-acee-4107-8215-d69045b866e3@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 <lmesnik at openjdk.org>
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: <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>
Message-ID: <IpYTuMjGKsKM_8igMeHvkW9SqBIP_PilGCrViwPXCKM=.81b88464-e00f-4d53-b826-322b68a38c61@github.com>

On Wed, 24 Dec 2025 23:53:39 GMT, Eunbin Son <duke at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <xGLvpwxwkXbq8EPuGRpgd6EhOBtZs8rB2gZ7jGBNaLA=.7bfda676-1464-411a-9e6e-b2fe5d8de68b@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <7RY770x8idjnbhLPr-btqU-nlvy72O9tlv47xHMZZqQ=.409f21a3-f066-4c2b-aa1c-2f54fd2647d7@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <e6DddvFE_6Ndhfx0RlIlVwYxpqIXUh1px9SO-xmA0S4=.a15d68fe-e912-4a31-9248-d2e49d99c696@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@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)

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: <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>
Message-ID: <O8xUaoNIiv6Ffn1NBTyBeHa5lS6FSNKS3G7U_aZo54U=.0f7b9e9b-4b0d-4d2d-9811-40ffb8713bb6@github.com>

On Tue, 6 Jan 2026 10:51:22 GMT, Kevin Walls <kevinw at openjdk.org> 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: <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>
Message-ID: <Oo6xeE8jAJ7yxl5lBp5_mdI-6_NI3e0TJlRe5ffXtg0=.73aeee65-6899-4bbf-8b0b-a7b92eb2b53a@github.com>

On Mon, 5 Jan 2026 22:20:06 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>
Message-ID: <s_EQtwTANnJ40e9oXriagQo4o_pd5SJWv1w35a0Rwno=.be25c431-8938-4026-9606-e10e5bbc1069@github.com>

On Tue, 6 Jan 2026 11:50:30 GMT, Kevin Walls <kevinw at openjdk.org> 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: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.

Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:

  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: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
Message-ID: <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>

On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable <duke at openjdk.org> 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: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
Message-ID: <8iF5lwO870gPlfcozjDBwgYE9hw0WxeIjVfGiTT2ZmA=.a7b55428-5686-4578-b71a-f5d47414b524@github.com>

On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable <duke at openjdk.org> 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <z8XTqcOfWtB1mx8uECUKqLc7bWhD2_fFZe0rYk2uzmI=.24c457f7-fc56-47d8-a449-2c40c7d02d43@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <z8XTqcOfWtB1mx8uECUKqLc7bWhD2_fFZe0rYk2uzmI=.24c457f7-fc56-47d8-a449-2c40c7d02d43@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
 <z8XTqcOfWtB1mx8uECUKqLc7bWhD2_fFZe0rYk2uzmI=.24c457f7-fc56-47d8-a449-2c40c7d02d43@github.com>
Message-ID: <Zwlzds_U5293SpW3CfPUgG0x2u2uw3TEj4WrUr8vJVk=.e9267100-a783-4efd-a979-0de79bf672d7@github.com>

On Wed, 7 Jan 2026 01:15:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
 <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
Message-ID: <Y5_mNmjjmMarr5d5NPbcv06zyT2FQh35o3TkJarbr1A=.b0715e43-a3fd-4301-b52e-fdf7e54821e9@github.com>

On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes <dholmes at openjdk.org> 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: <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
Message-ID: <91jC9ajf0mhxmgQignRJR5wG65YPJ3EnPsMD31KDQkw=.f1710749-f5ef-4c15-bb25-a68535976115@github.com>

On Fri, 19 Dec 2025 14:47:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve exception

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: <Zwlzds_U5293SpW3CfPUgG0x2u2uw3TEj4WrUr8vJVk=.e9267100-a783-4efd-a979-0de79bf672d7@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
 <z8XTqcOfWtB1mx8uECUKqLc7bWhD2_fFZe0rYk2uzmI=.24c457f7-fc56-47d8-a449-2c40c7d02d43@github.com>
 <Zwlzds_U5293SpW3CfPUgG0x2u2uw3TEj4WrUr8vJVk=.e9267100-a783-4efd-a979-0de79bf672d7@github.com>
Message-ID: <SSgkOQei2YU0cJ-_KiWuT0HqRKkHavqd6NtakU3XloM=.0a01d995-7933-4e86-a06f-1946610319e1@github.com>

On Wed, 7 Jan 2026 02:07:39 GMT, Chad Rakoczy <duke at openjdk.org> 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <5JRD8nCTROjlpIlxJPW0MEOZFzHyUwz-4elmy1aEqPo=.0d1f1a17-5d5e-47b2-b50f-2a5da501a2f1@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
Message-ID: <Uc6-L2ELP00ItOYnweeR8xWiEK48tiHnf-yMZbustiU=.00a1ca86-0413-4a15-9fdf-2451207d1e3f@github.com>

> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
> 
> 
> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
> 2025-12-17 06:34:37
> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x000078a8bc13f200, length=10, elements={
> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>    :
> 
> 
> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
> 
> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
> 
> 
> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
> / # /usr/lib/jvm/jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
> 
> / # ls -l /proc/1/cwd
> ls: /proc/1/cwd: cannot read link: Permission denied
> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
> 
> 
> 
> After this change, we can see following exception on the console of jcmd when we encounter this situation:
> 
> # jcmd 1 VM.version
> 1:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm...

Yasumasa Suenaga has updated the pull request incrementally with 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: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <bQW194zr3NSDdYd1UFtYh7bsrvA18aQrbewJP_Gc3KE=.f17ff302-17f2-47e5-bdc1-5ab0a53708f2@github.com>
 <91jC9ajf0mhxmgQignRJR5wG65YPJ3EnPsMD31KDQkw=.f1710749-f5ef-4c15-bb25-a68535976115@github.com>
Message-ID: <vD87OFZyW_pRdJQ5W2dPsltXZZMZVXZxq8gKbcZzAwI=.8b7cf823-7be3-4266-be0d-712f9fcf3cc4@github.com>

On Wed, 7 Jan 2026 03:14:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>

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


<img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />

This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.

<img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />

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: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
Message-ID: <qijqiuex_WSeBaU6kgR9hu2YMAlvYgt6MYcpbJK7rSw=.f755a078-2833-400a-9e16-96f585d09482@github.com>

On Tue, 6 Jan 2026 09:47:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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
> 
> 
> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
> 
> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
> 
> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
> 
> 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: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
Message-ID: <q03ycurNrC_Oyn-fGH4hn8Zt_FHry8KByk2qhisZ8c4=.76547ec9-0138-40e7-a6db-ea4d58cd350a@github.com>

> 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
> 
> 
> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
> 
> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
> 
> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
> 
> 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: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
Message-ID: <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>

On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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<Float16> 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: <Uc6-L2ELP00ItOYnweeR8xWiEK48tiHnf-yMZbustiU=.00a1ca86-0413-4a15-9fdf-2451207d1e3f@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <Uc6-L2ELP00ItOYnweeR8xWiEK48tiHnf-yMZbustiU=.00a1ca86-0413-4a15-9fdf-2451207d1e3f@github.com>
Message-ID: <mEf1IQS6SvHgLa8IEKGJTKXuSDvzK3BfzfM_SSHbrGA=.a0735d61-0303-4726-a0a8-08751f350ca3@github.com>

On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with 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: <qijqiuex_WSeBaU6kgR9hu2YMAlvYgt6MYcpbJK7rSw=.f755a078-2833-400a-9e16-96f585d09482@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
 <qijqiuex_WSeBaU6kgR9hu2YMAlvYgt6MYcpbJK7rSw=.f755a078-2833-400a-9e16-96f585d09482@github.com>
Message-ID: <nUP8Xi6QvFhmcWEzgnijHbYYO4gBuWF5TWaS6kwdlPI=.6fa65443-5156-41be-ab0b-a3f97ca4bb4e@github.com>

On Wed, 7 Jan 2026 05:27:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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
>> 
>> 
>> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
>> 
>> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
>> 
>> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
>> 
>> 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: <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
 <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
Message-ID: <BTvNZTd5A6PrXD1gARtQ0r3wtAkpzcjbunbkBFPwIQs=.c277bf29-1c32-45ef-98a1-536db7f52808@github.com>

On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang <fyang at openjdk.org> 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<Float16> 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: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
Message-ID: <QWOVCH2EToUov3bumijjB8zjuNL_vZxPjR9p19PJJCg=.4be5beb1-6f7c-4eda-903f-cd8dd279edd1@github.com>

On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable <duke at openjdk.org> 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: <e6DddvFE_6Ndhfx0RlIlVwYxpqIXUh1px9SO-xmA0S4=.a15d68fe-e912-4a31-9248-d2e49d99c696@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <e6DddvFE_6Ndhfx0RlIlVwYxpqIXUh1px9SO-xmA0S4=.a15d68fe-e912-4a31-9248-d2e49d99c696@github.com>
Message-ID: <A5s1xHzzFKzDOXBh3nkZdnEtdrrr8ZLtDCB4YNRNCMg=.821fb874-f6fb-4f73-b80d-fa46d0f9435f@github.com>

On Tue, 6 Jan 2026 21:20:29 GMT, David Holmes <dholmes at openjdk.org> 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: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
Message-ID: <c5XggveGMIFLLplDHzxxMXoAxLyfv8FcR3MXU6vuwvI=.c36a17b5-f353-42e7-9cfa-21fc08e90d2f@github.com>

> ### Summary
> Fix incorrect regex usage in CoreUtils.getCoreFileLocation.
> 
> ### Description
> CoreUtils.getCoreFileLocation uses String.split("\s", 2).
> The string literal "\s" represents a backspace character, not a whitespace regex.
> As a result, the split operation does not separate fields on whitespace.
> This change replaces the pattern with `"\\s+"` to correctly split on whitespace.
> No other logic is modified.
> 
> ### Bug ID :  JDK-8374341 
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341

Eunbin Son has updated the pull request incrementally with one additional commit since the last revision:

  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: <IpYTuMjGKsKM_8igMeHvkW9SqBIP_PilGCrViwPXCKM=.81b88464-e00f-4d53-b826-322b68a38c61@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>
 <IpYTuMjGKsKM_8igMeHvkW9SqBIP_PilGCrViwPXCKM=.81b88464-e00f-4d53-b826-322b68a38c61@github.com>
Message-ID: <YvxB4mJezSECQoYm_injxXIuSMMPGnvHceh-HcFhDNA=.cccd20f8-a26d-4b92-b6be-99da94e89b9a@github.com>

On Tue, 6 Jan 2026 19:26:46 GMT, Kevin Walls <kevinw at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
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: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> 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: <A5s1xHzzFKzDOXBh3nkZdnEtdrrr8ZLtDCB4YNRNCMg=.821fb874-f6fb-4f73-b80d-fa46d0f9435f@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <e6DddvFE_6Ndhfx0RlIlVwYxpqIXUh1px9SO-xmA0S4=.a15d68fe-e912-4a31-9248-d2e49d99c696@github.com>
 <A5s1xHzzFKzDOXBh3nkZdnEtdrrr8ZLtDCB4YNRNCMg=.821fb874-f6fb-4f73-b80d-fa46d0f9435f@github.com>
Message-ID: <X5aWlQdWWqEIGgLsUPJeyIgOBYAJE4J7QgRl6Fv5ZfA=.93727dfd-1300-45f6-aec5-5a43534b3091@github.com>

On Wed, 7 Jan 2026 10:31:51 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <YvxB4mJezSECQoYm_injxXIuSMMPGnvHceh-HcFhDNA=.cccd20f8-a26d-4b92-b6be-99da94e89b9a@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>
 <IpYTuMjGKsKM_8igMeHvkW9SqBIP_PilGCrViwPXCKM=.81b88464-e00f-4d53-b826-322b68a38c61@github.com>
 <YvxB4mJezSECQoYm_injxXIuSMMPGnvHceh-HcFhDNA=.cccd20f8-a26d-4b92-b6be-99da94e89b9a@github.com>
Message-ID: <yWuEPeCPmICweX_LRS3UYGSWxpTkEl61BEKXk4Ravt4=.b76274ca-805c-42b2-9a5b-38e24fc6d2ab@github.com>

On Wed, 7 Jan 2026 12:37:16 GMT, Eunbin Son <duke at openjdk.org> 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: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
Message-ID: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com>

On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <JtG686KqPyP4ajAJBLzETBnp-LgqMs7FeR8IEKxvuxo=.3af73025-5da7-43a7-93b5-e55581b478d5@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <nEhxpWx2fWmVrJ5ayFFG5F5YJrzx3Ap18ruJJ9XfYLA=.f7d0ecf6-1ddd-4873-b07e-2b666098b466@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <umGkuNCiL2nogfZNZGv4WnJHxTo0C50tNDuBzkMfeo0=.35e2bbb2-1c1a-435a-8598-118076de4ffa@github.com>

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

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <n4hleu94KqlqrJNQp55kja8-dnQZg1nYxUXKwtODIbY=.7e19ca72-3cca-48a2-a915-4fb4e2b99ad2@github.com>

> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
> 
> This is fixed by a small tweak in the function
> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
> 
> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
> 
> Testing:
>  - In progress: mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <-N01CwL7Mj3y4_P1Ytg31pJX08zT0P4PgkkGkNepW5g=.de7ea489-a0ec-4b3c-80c0-e73eefb83e0c@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <SSgkOQei2YU0cJ-_KiWuT0HqRKkHavqd6NtakU3XloM=.0a01d995-7933-4e86-a06f-1946610319e1@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
 <z8XTqcOfWtB1mx8uECUKqLc7bWhD2_fFZe0rYk2uzmI=.24c457f7-fc56-47d8-a449-2c40c7d02d43@github.com>
 <Zwlzds_U5293SpW3CfPUgG0x2u2uw3TEj4WrUr8vJVk=.e9267100-a783-4efd-a979-0de79bf672d7@github.com>
 <SSgkOQei2YU0cJ-_KiWuT0HqRKkHavqd6NtakU3XloM=.0a01d995-7933-4e86-a06f-1946610319e1@github.com>
Message-ID: <eCPE78UxUXUYv2ITmblJotRweUtIOpgIBehZ2NkzaQo=.687ea84e-b915-446a-ace2-754efc087c23@github.com>

On Wed, 7 Jan 2026 03:45:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
Message-ID: <19hYxh6gAEz28Kv7lxT9Xli8pyQ7Z1z-BM0u_sryPCw=.069435be-3222-49be-949a-ae79bad51b3b@github.com>

On Fri, 5 Dec 2025 22:23:46 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
> 
> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. 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 <chadrako at amazon.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>

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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
Message-ID: <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com>

On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>

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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
Message-ID: <KoUai6zNa5re2Y2o8c3OeBQ9UIOG09HvMKeSFZ-fDnI=.6ef4a4fb-a4f4-4f7d-a79b-c157a431a416@github.com>

On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls <kevinw at openjdk.org> 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: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <InEGAmmLbM5ZUT0XAkSHwwP2hatQkFvdjdXZ4NnJ2_0=.dcd7ac1a-e08a-4f91-8876-3d80ff9481cd@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request 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: <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>
Message-ID: <focJ2L-flfGlRm_9laFb0nZXLPtfz4Eu-ygA3nuLc1Q=.cb585031-cd65-4094-935d-eef4e8f94eb0@github.com>

On Thu, 8 Jan 2026 10:00:08 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <focJ2L-flfGlRm_9laFb0nZXLPtfz4Eu-ygA3nuLc1Q=.cb585031-cd65-4094-935d-eef4e8f94eb0@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>
 <focJ2L-flfGlRm_9laFb0nZXLPtfz4Eu-ygA3nuLc1Q=.cb585031-cd65-4094-935d-eef4e8f94eb0@github.com>
Message-ID: <Dpu0vYd8NmSUKZ0Q0A8icf90J_yPMxIJ8sx_jr_mbgM=.af1e3ebe-4b5c-47ac-9be0-6a9605d542f5@github.com>

On Thu, 8 Jan 2026 19:17:40 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@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.

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

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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@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 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: <Dpu0vYd8NmSUKZ0Q0A8icf90J_yPMxIJ8sx_jr_mbgM=.af1e3ebe-4b5c-47ac-9be0-6a9605d542f5@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>
 <focJ2L-flfGlRm_9laFb0nZXLPtfz4Eu-ygA3nuLc1Q=.cb585031-cd65-4094-935d-eef4e8f94eb0@github.com>
 <Dpu0vYd8NmSUKZ0Q0A8icf90J_yPMxIJ8sx_jr_mbgM=.af1e3ebe-4b5c-47ac-9be0-6a9605d542f5@github.com>
Message-ID: <bxWOPDyQgWis5stX6uuoyQTjqf_sPEfM8XVv2ecJuuA=.ae38ccb2-cfa2-4691-b3ef-9871bf2cfc12@github.com>

On Thu, 8 Jan 2026 19:37:17 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <o3an77G-d1JaxsjRhw5YFL0rtgqMEno0Mhd3WUeoQ50=.a78fc05b-b71f-4a16-9561-acc3ba9e5b32@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@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:

  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: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <HP2MuR3CPGXVm15_SO6oYLX6hg8YEB0qnBGSFQEMApM=.fe2d338c-ce68-4b4f-a351-c87a23cc258a@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
Message-ID: <gaKOVlZslBZPD6o6QUsd6SCkZVP4R0qyqewR3xCQ4vQ=.8aa4b6cd-8ae7-4dd1-9363-0e282b25b17b@github.com>

On Sat, 27 Dec 2025 11:25:25 GMT, Harald Eilertsen <haraldei at openjdk.org> 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: <bxWOPDyQgWis5stX6uuoyQTjqf_sPEfM8XVv2ecJuuA=.ae38ccb2-cfa2-4691-b3ef-9871bf2cfc12@github.com>
References: <gjimy3dnEX6xbKHJR0Ig95zh0r3cH54xqfud87FGLRU=.4849eeb7-2bc9-4d8a-806d-1290b799f017@github.com>
 <FJADV7PjPvqCrtkKMtUSxPsZzDC5EowtYwHQx3KaYTg=.d3fb3c63-def6-4ac0-84de-827d18a6abda@github.com>
 <focJ2L-flfGlRm_9laFb0nZXLPtfz4Eu-ygA3nuLc1Q=.cb585031-cd65-4094-935d-eef4e8f94eb0@github.com>
 <Dpu0vYd8NmSUKZ0Q0A8icf90J_yPMxIJ8sx_jr_mbgM=.af1e3ebe-4b5c-47ac-9be0-6a9605d542f5@github.com>
 <bxWOPDyQgWis5stX6uuoyQTjqf_sPEfM8XVv2ecJuuA=.ae38ccb2-cfa2-4691-b3ef-9871bf2cfc12@github.com>
Message-ID: <3AGexKsPQQPTzmPKrILuKAAgn5vEhJNkghfs8k7soXw=.ef813049-93ed-4ec9-b0ed-04fa0e6652b8@github.com>

On Thu, 8 Jan 2026 19:58:00 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <vpUid8KNRxuS_f7Ra4ybZ7hHRq0mYyDR2o0q4gLaY74=.19c8e5ad-8fd8-42f0-9fb1-10ae2d5c224d@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <HP2MuR3CPGXVm15_SO6oYLX6hg8YEB0qnBGSFQEMApM=.fe2d338c-ce68-4b4f-a351-c87a23cc258a@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
 <HP2MuR3CPGXVm15_SO6oYLX6hg8YEB0qnBGSFQEMApM=.fe2d338c-ce68-4b4f-a351-c87a23cc258a@github.com>
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 <kfarrell at openjdk.org> 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: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@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 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
Message-ID: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>

On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls <kevinw at openjdk.org> 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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
Message-ID: <KnQP4vEKTWvkf_favEmj3gW66d4xNIQrD9VBRSbaOVE=.cbaa3b2a-a0eb-4d4e-99a1-03543335831c@github.com>

On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls <kevinw at openjdk.org> 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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
Message-ID: <YbzJ0UHG3cY6_k4rJnqQdL6Cr4V7Zvqa54LDN4H_Eh8=.fdacd01d-c0ae-42e1-83a8-8bf9904bb114@github.com>

On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls <kevinw at openjdk.org> 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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
 <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 <lmesnik at openjdk.org> 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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
 <31OU-ADxKwxJyb265AaauXVTI0xR943oSmgX3PnvfX8=.ef7d748e-d1f5-4625-90c1-775e5212396a@github.com>
Message-ID: <EVoc7BYvjV8afnU76rCvyK8qMo87uHgawFmQa6NQ5V4=.35d51e87-5ed8-4687-9a41-d47470a3b0dc@github.com>

On Thu, 8 Jan 2026 04:41:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
 <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
Message-ID: <BPQSgCDzySWsGDQ8aLbw6-lrt6QUvf0_1ji46PKKtGg=.b09d4fe8-5715-4b25-a834-0426dd4fdc09@github.com>

On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable <duke at openjdk.org> 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: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> 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: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com>

On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell <kfarrell at openjdk.org> 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==<url>  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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
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: <YbzJ0UHG3cY6_k4rJnqQdL6Cr4V7Zvqa54LDN4H_Eh8=.fdacd01d-c0ae-42e1-83a8-8bf9904bb114@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
 <YbzJ0UHG3cY6_k4rJnqQdL6Cr4V7Zvqa54LDN4H_Eh8=.fdacd01d-c0ae-42e1-83a8-8bf9904bb114@github.com>
Message-ID: <g9PXQIqKr7-ROSDlkkH6aljYrfrsDAKraQUWahWuTik=.942a8365-a0d4-46af-8f0f-b403cffc0db0@github.com>

On Fri, 9 Jan 2026 03:43:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
Message-ID: <WSQMKE16MyCIntyIfQRQmee3OBGNrD2lVUGd_1D4XPY=.4ca9b2e6-99c0-4302-8798-79d6bd99af1c@github.com>

> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
Message-ID: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>

On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell <kfarrell at openjdk.org> 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 <PID> 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: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <yLCUFE0lN2uvHBYlGjPyKvatQ1Y09nRAGeK1rLnj0qM=.6784a53d-6035-4204-81b5-083a9a009ea0@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 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: <AVT1wREU7BFMhtmv1zulfmbPlmPURe4qfcehfMILeDY=.d4cdcaa7-9726-48f6-8730-7f5b0dc57532@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
 <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
 <AVT1wREU7BFMhtmv1zulfmbPlmPURe4qfcehfMILeDY=.d4cdcaa7-9726-48f6-8730-7f5b0dc57532@github.com>
Message-ID: <Zdt4kyYaXa4QTXrKoqv-5TyrlP6CxmNIe0qW_AAkX20=.1d42961f-660a-4856-aab1-d4254bd72697@github.com>

On Mon, 24 Nov 2025 01:32:19 GMT, David Holmes <dholmes at openjdk.org> 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: <yWuEPeCPmICweX_LRS3UYGSWxpTkEl61BEKXk4Ravt4=.b76274ca-805c-42b2-9a5b-38e24fc6d2ab@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <M3P3zKdImGGHGnLgRXqwIH4MLndu7okBjG3lANirhMQ=.ff04199d-baeb-4575-aaba-2e3f6158acb6@github.com>
 <IpYTuMjGKsKM_8igMeHvkW9SqBIP_PilGCrViwPXCKM=.81b88464-e00f-4d53-b826-322b68a38c61@github.com>
 <YvxB4mJezSECQoYm_injxXIuSMMPGnvHceh-HcFhDNA=.cccd20f8-a26d-4b92-b6be-99da94e89b9a@github.com>
 <yWuEPeCPmICweX_LRS3UYGSWxpTkEl61BEKXk4Ravt4=.b76274ca-805c-42b2-9a5b-38e24fc6d2ab@github.com>
Message-ID: <Am0eFzFoVi_VSERLkxCRrpmWPIMeQnQxPrZbkGTHp-U=.5af2b620-fcef-4ee0-a5b3-c6e6dddea367@github.com>

On Wed, 7 Jan 2026 19:56:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com>
Message-ID: <e7U17tka6dcFv-kMzf_MkQxkldK7pDhg8QNET6u88KQ=.4d540f7b-debf-462c-a8c8-435aafbc4dce@github.com>

On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son <duke at openjdk.org> 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: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>

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: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
 <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
Message-ID: <CuZJc6rlOnkQQcx_MnFCf88oo9v3VqdlH5eiRV6mNKs=.71e51174-39be-4540-b939-9b8ef01eef76@github.com>

On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <WSQMKE16MyCIntyIfQRQmee3OBGNrD2lVUGd_1D4XPY=.4ca9b2e6-99c0-4302-8798-79d6bd99af1c@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
 <WSQMKE16MyCIntyIfQRQmee3OBGNrD2lVUGd_1D4XPY=.4ca9b2e6-99c0-4302-8798-79d6bd99af1c@github.com>
Message-ID: <h_mZJVeIXWia3CLmgUDwCs8qd0tW1OynHl0gYhugw6I=.2ec8a246-a176-45b6-b194-1a4215a6cd53@github.com>

On Fri, 9 Jan 2026 10:13:02 GMT, Kevin Walls <kevinw at openjdk.org> 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: <WSQMKE16MyCIntyIfQRQmee3OBGNrD2lVUGd_1D4XPY=.4ca9b2e6-99c0-4302-8798-79d6bd99af1c@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
 <WSQMKE16MyCIntyIfQRQmee3OBGNrD2lVUGd_1D4XPY=.4ca9b2e6-99c0-4302-8798-79d6bd99af1c@github.com>
Message-ID: <3G7VsHQ9GTaR5sHQ3lFTMzZWwrLwMdIDdkYfjqlYU-w=.f605dd27-50af-4579-a485-0df6b1f0f60f@github.com>

On Fri, 9 Jan 2026 10:13:02 GMT, Kevin Walls <kevinw at openjdk.org> 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: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
References: <GRB0G0skcYnsc07AsfK2dif2VLeO665vZqd8UVC4w_o=.e09f58b2-aec6-4055-83d9-896d920d44f1@github.com>
Message-ID: <m-NDBy31KdLUINXnmOGxYbFpOcCbdyUhUYB8Iy7zwLs=.09c69adb-8b06-4fa0-bd11-a8a3be07bb17@github.com>

On Thu, 8 Jan 2026 17:43:16 GMT, Kevin Walls <kevinw at openjdk.org> 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 <kevinw at openjdk.org>
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: <QWOVCH2EToUov3bumijjB8zjuNL_vZxPjR9p19PJJCg=.4be5beb1-6f7c-4eda-903f-cd8dd279edd1@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <QWOVCH2EToUov3bumijjB8zjuNL_vZxPjR9p19PJJCg=.4be5beb1-6f7c-4eda-903f-cd8dd279edd1@github.com>
Message-ID: <VULc21ptrD2IfTknhwfwlS7JMnS_Uc5CY4PwJqUnsm4=.2bee385a-529a-49a6-908c-30f9d5e16047@github.com>

On Wed, 7 Jan 2026 10:07:02 GMT, Kevin Walls <kevinw at openjdk.org> 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: <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
Message-ID: <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>

On Tue, 6 Jan 2026 23:46:44 GMT, David Holmes <dholmes at openjdk.org> 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: <cvP38XAj4Tbw6y7Eftf6SxuG0-LY_8TjinhA4uOPWOw=.7dc4d9d3-873d-43ce-aa27-794cf831cf2d@github.com>

On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [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: <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
Message-ID: <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@github.com>

On Fri, 9 Jan 2026 17:26:30 GMT, Larry Cable <duke at openjdk.org> 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: <VULc21ptrD2IfTknhwfwlS7JMnS_Uc5CY4PwJqUnsm4=.2bee385a-529a-49a6-908c-30f9d5e16047@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <QWOVCH2EToUov3bumijjB8zjuNL_vZxPjR9p19PJJCg=.4be5beb1-6f7c-4eda-903f-cd8dd279edd1@github.com>
 <VULc21ptrD2IfTknhwfwlS7JMnS_Uc5CY4PwJqUnsm4=.2bee385a-529a-49a6-908c-30f9d5e16047@github.com>
Message-ID: <BUkg7YFs6rNRiu41YNOznf4dnRPIQlyiT1mGnJsbeP4=.7eaed851-0761-4220-b3ba-ca35241ab498@github.com>

On Fri, 9 Jan 2026 17:22:04 GMT, Larry Cable <duke at openjdk.org> 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: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
Message-ID: <A1xpruaOmonYcZxYYxwYaDktQQZ75RwO0gQDI6vzIds=.51608f18-e837-4947-9d66-25a1bf543851@github.com>

On Fri, 9 Jan 2026 13:41:22 GMT, SendaoYan <syan at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
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: <w90u_S7HydH2SbJiSto4Ycoy7rN8uSP2FG-xCvID61w=.4f4a663a-e306-4efd-aec2-ef610817c43c@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <hTVz3SJGdD1IkRufkX5dIEmYO996y7nyqUtAsKfVYL8=.16ae6688-d132-4e52-9baa-613f2e018ba3@github.com>
 <GAlogwnN7y7jIhmeVF_IPSdEylEnUgXTWkqeHoHCUbk=.5f8fdec6-c925-4b1b-bc12-1cb3f9666d0e@github.com>
 <w90u_S7HydH2SbJiSto4Ycoy7rN8uSP2FG-xCvID61w=.4f4a663a-e306-4efd-aec2-ef610817c43c@github.com>
Message-ID: <E-hGRWWbPOPkNKMlNAX0RhjSc7M-FGJifTktSdGZ1qc=.c9741e67-3164-44d1-9382-b98d2f2199f6@github.com>

On Tue, 23 Dec 2025 00:02:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <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 <duke at openjdk.org> 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.<pid>.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: <vxyAZN9CJfnXxyoZnAki_Af03obcP7fhasamLZHhueE=.38699046-8566-48e3-81ca-96cae2b4935f@github.com>

On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [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: <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
Message-ID: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com>

On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [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:  * <p>The method <code>unloadClass()</code> 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: <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
 <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@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 <duke at openjdk.org> 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: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
Message-ID: <GcJ3guwzIkfLmGObvDoVh3fQA9pKWYtCnsD8Sw0lgp0=.368f1e5a-3dd7-4aff-9cb7-2d865fa2be80@github.com>

On Sat, 3 Jan 2026 10:22:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
> 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 <signal handler called>
> 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("<signal handler called>")) {

You are using "<signal handler called>" 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <hbLtIMP5JRTZp7tNVuClrg5Fcdbdl0drnkzB0XB-8mY=.221cb843-3e43-459e-b1be-c63eb579f5a9@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:

  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: <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
Message-ID: <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>

On Sun, 4 Jan 2026 05:29:58 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <IZV_SITBCgWtL0G8r4AQdVMvrO6Tx_rn8259ByYVEJM=.f92a03bc-3957-4138-b168-38f560b493ad@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)

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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
Message-ID: <CVqB9cLMvw7VP2oxjpxnXncJtrPgccKTGAZEGpcK34U=.e1b149ef-a517-4f56-a974-67b2403c236d@github.com>

> 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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
 <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 <sspitsyn at openjdk.org> 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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
Message-ID: <_sBwN1Xl6x2wsJWWb3evXRSbRj1S4xEhpU1iVzr6zx4=.d5d7f38e-b12c-4f74-bac0-56a6e16127b3@github.com>

On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <GcJ3guwzIkfLmGObvDoVh3fQA9pKWYtCnsD8Sw0lgp0=.368f1e5a-3dd7-4aff-9cb7-2d865fa2be80@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <GcJ3guwzIkfLmGObvDoVh3fQA9pKWYtCnsD8Sw0lgp0=.368f1e5a-3dd7-4aff-9cb7-2d865fa2be80@github.com>
Message-ID: <Xlb73lkLhY-vziXjfCeq31B6aY9_8OGBHAejiU02lC0=.f3eb143e-f646-4dc4-93ab-d33e0e1e5e44@github.com>

On Fri, 9 Jan 2026 20:11:15 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <CVqB9cLMvw7VP2oxjpxnXncJtrPgccKTGAZEGpcK34U=.e1b149ef-a517-4f56-a974-67b2403c236d@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
 <CVqB9cLMvw7VP2oxjpxnXncJtrPgccKTGAZEGpcK34U=.e1b149ef-a517-4f56-a974-67b2403c236d@github.com>
Message-ID: <oyLeaZtQwEVbMEiOsPon36sztSFKIlWHIQYh79d0koY=.cc757642-b965-49f9-bc65-18423dceb732@github.com>

On Sat, 10 Jan 2026 00:59:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
Message-ID: <eGdIDt3MqwOYT44J5k5P2xUZ6i9bWGefU25OvqXdPrc=.4b2233d5-db19-473f-bcff-25d4469c98da@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 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java
  
  Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

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

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: <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
Message-ID: <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>

On Fri, 9 Jan 2026 20:24:15 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
Message-ID: <JwrGZASEi0H2ODjy-LgtmlJvIJ8_rj9ZzEHObLOKZMI=.ea41d560-192d-46a9-963f-0d7552c0b78f@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 <StubRoutines>
> 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 <signal handler called>
> 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: <GcJ3guwzIkfLmGObvDoVh3fQA9pKWYtCnsD8Sw0lgp0=.368f1e5a-3dd7-4aff-9cb7-2d865fa2be80@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <GcJ3guwzIkfLmGObvDoVh3fQA9pKWYtCnsD8Sw0lgp0=.368f1e5a-3dd7-4aff-9cb7-2d865fa2be80@github.com>
Message-ID: <hN36dn2jikKzF2Liq9znzXWaBMU_9Ljf9nFV4jlVzMc=.77a75fb3-9b99-4c66-869f-5d04bfddcdfe@github.com>

On Fri, 9 Jan 2026 20:07:41 GMT, Chris Plummer <cjplummer at openjdk.org> 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("<signal handler called>")) {
> 
> You are using "<signal handler called>" 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
Message-ID: <scLB3zYGWx9XRmdzDtYBixNNzbXDeZZ8ewHOoroORGs=.cf8cfb64-c611-4400-a877-c528a5a8a0f8@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 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 <chris.plummer at oracle.com>
 - 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: <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
Message-ID: <VwnEZSb3BrorMUwnDweQY_wjk9KpbqD8689CYTcsS_8=.f6ecdfed-3008-4b7f-9d94-84ce75748910@github.com>

On Fri, 9 Jan 2026 20:27:28 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
Message-ID: <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>

> 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: <A1xpruaOmonYcZxYYxwYaDktQQZ75RwO0gQDI6vzIds=.51608f18-e837-4947-9d66-25a1bf543851@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <A1xpruaOmonYcZxYYxwYaDktQQZ75RwO0gQDI6vzIds=.51608f18-e837-4947-9d66-25a1bf543851@github.com>
Message-ID: <89Q1HvAk4uiwjFQ0kv6QbXIBMVhF791BVL4dX0DKIk8=.ffbd43d0-875a-40f0-9396-e6c3e3e28287@github.com>

On Fri, 9 Jan 2026 17:59:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <xEDkdIhzs0VPul1iQsDmuUiOl5cb5Nsl1qp8QOUIg_U=.7d2ab037-91af-4263-9e1c-eb8edd795814@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [x] All jtreg tests by fastdebug build

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

  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: <vxyAZN9CJfnXxyoZnAki_Af03obcP7fhasamLZHhueE=.38699046-8566-48e3-81ca-96cae2b4935f@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com>
 <vxyAZN9CJfnXxyoZnAki_Af03obcP7fhasamLZHhueE=.38699046-8566-48e3-81ca-96cae2b4935f@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 <cjplummer at openjdk.org> 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>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
 <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com>
Message-ID: <XnVnCIfNTlvwhT3K8c4o1j125S8pvYcxCcXD5AcjlWw=.2ba51210-2e4b-4edc-a6a9-1085f69a236d@github.com>

On Wed, 24 Dec 2025 02:05:21 GMT, Chris Plummer <cjplummer at openjdk.org> 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:  * <p>The method <code>unloadClass()</code> 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
Message-ID: <b3aaUJeAxQgH8yPblniMIPLblzECaWrIrqdhvcEJ50o=.3151742a-8653-4337-907e-f6cb70ac78de@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 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 <chris.plummer at oracle.com>
 - 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: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
Message-ID: <SSdXzopYuA2VJN4uC2otCbsw9cPBfW5zICdLTUVCJNw=.c1d9c380-a4fe-4a01-b053-1832345ea24e@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 <StubRoutines>
> 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 <signal handler called>
> 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
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: <CVqB9cLMvw7VP2oxjpxnXncJtrPgccKTGAZEGpcK34U=.e1b149ef-a517-4f56-a974-67b2403c236d@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
 <CVqB9cLMvw7VP2oxjpxnXncJtrPgccKTGAZEGpcK34U=.e1b149ef-a517-4f56-a974-67b2403c236d@github.com>
Message-ID: <2cxzCT5jafMBUQoLaIftouhYRezhyrldfVyBW0IImAE=.77904de3-7913-47b7-b750-11e4ed6305f9@github.com>

On Sat, 10 Jan 2026 00:59:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
References: <XMMOCJwJrICTmWTrjihWYEx7n_9AHeE64nrVo9yOjAY=.cab57973-0b9e-46d2-8410-4ad1af2b55e7@github.com>
Message-ID: <OvGmBc1Mw5nnSukzvUesJfLpLO1MydTBpkS1VNp-G7U=.cfe45e69-d4e6-4de4-bfa3-c5567ae69dcf@github.com>

On Thu, 8 Jan 2026 01:07:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
Message-ID: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@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 <StubRoutines>
> 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 <signal handler called>
> 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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <JfgPZSp1jHAwpyVoHMMu-R2ifc8uWSgdKr3QeFvlKio=.d56530fd-8758-4905-b896-0e6063b5fafb@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
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 <chris.plummer at oracle.com>
 - 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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <U8-eXczWi5Xr6X3Kc9ajo2h1hVMDF7-qsflW2uaxePc=.c41a57fb-63c2-44a2-b0e8-d099a94524a5@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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 <Java_jdk_test_lib_apps_LingeredApp_crash>:
 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: <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
Message-ID: <k6WCSoKy5AS1bjpaSw3yj7mK-khPifdbXOoe3wsEWTk=.a8e372f5-07c8-46bd-8ff8-f01ebab6ce60@github.com>

On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan <syan at openjdk.org> 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: <jpwqK3H_TNXpnxw7EbkAMObsFxW125r52P2a2rZ2A00=.a2095d49-77b3-428f-97a2-b5482e4eaefe@github.com>

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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com>
 <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com>
Message-ID: <YkZYGAJz2NV7CeRdS7_MS4vCx3fCWTx8gU1aqWmjlZ0=.333579bc-1a35-4a31-aec0-7065b2a1e3de@github.com>

On Fri, 9 Jan 2026 19:42:11 GMT, Chris Plummer <cjplummer at openjdk.org> 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.<pid>.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: <XtPOl54uhDe9o3Q6cNO9w-ffhuMC6LsbNVs222BhAdA=.83ae5455-b8cb-403e-86fd-d149ec86dcd8@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)

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: <XtPOl54uhDe9o3Q6cNO9w-ffhuMC6LsbNVs222BhAdA=.83ae5455-b8cb-403e-86fd-d149ec86dcd8@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <XtPOl54uhDe9o3Q6cNO9w-ffhuMC6LsbNVs222BhAdA=.83ae5455-b8cb-403e-86fd-d149ec86dcd8@github.com>
Message-ID: <dwsOLnJcZ3XBKkDrfz-WYtR5yr2U4fj0YspzdZ61Tqw=.0853a224-db62-4a39-ba03-9bf501cff65e@github.com>

On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable <duke at openjdk.org> 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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <wRtGFLTUjb-iEOmz6WzcYIk7p4HXQGzF1owdwq1WgUo=.48f647ba-7856-43bf-8248-dec308b18c05@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JNIenv use and update shouldExit

After this change the test is failing with:

<COMPILED_METHOD_LOAD>:   name: compiledMethod, code: 0x0000ffff6c9ed5c0
<COMPILED_METHOD_LOAD>:   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: <wRtGFLTUjb-iEOmz6WzcYIk7p4HXQGzF1owdwq1WgUo=.48f647ba-7856-43bf-8248-dec308b18c05@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
 <wRtGFLTUjb-iEOmz6WzcYIk7p4HXQGzF1owdwq1WgUo=.48f647ba-7856-43bf-8248-dec308b18c05@github.com>
Message-ID: <S3Ej6s6Fe_4d1PYB2QTb-tcGy_evVd0BYdWrKmVPIvw=.a0a426b4-93c6-4fdd-8ecd-eec4ffcd756f@github.com>

On Mon, 12 Jan 2026 22:19:39 GMT, David Holmes <dholmes at openjdk.org> 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:
> 
> <COMPILED_METHOD_LOAD>:   name: compiledMethod, code: 0x0000ffff6c9ed5c0
> <COMPILED_METHOD_LOAD>:   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: <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
References: <Xlq_LvOSeEyIIF_VX4GTDxalpiLxmzWBH_NynyUGGII=.f59e3a0f-136b-4ae7-b3c2-97f8aa1eb34e@github.com>
 <QtdVMDyB1HbT7ibW1JMN-Dy7DCGPUgcgslhK2ZUGp7g=.80bd336e-80c5-4ec8-9f08-2106fb1c3d4d@github.com>
Message-ID: <2dJeB8VUOrH35LDp73WoiKbCi8Jt4kVt3bYtur_2CnI=.bcf814ea-3850-44aa-b9bf-f02af01e982f@github.com>

On Tue, 6 Jan 2026 22:47:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150)
>> 
>> The test checks for JVMTI `COMPILED_METHOD_LOAD` and `COMPILED_METHOD_UNLOAD` events to be published for a relocated nmethod. It would originally intermittently fail if the JVM exited before it had time to publish the events so now it loops and forces GCs to encourage event publishing. The test fails if the events are received in the incorrect order (such as an unload before a load) or if the correct events are not received and the test times out.
>
> Chad Rakoczy has updated the pull request incrementally with 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: <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
Message-ID: <xCHd34dGFQvWq8zIAbu3XORZ0ChVEIX7IB8L3wjDIWM=.f01ce20e-7c8d-4a07-a3e6-2dc892b22ea4@github.com>

On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan <syan at openjdk.org> 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: <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
Message-ID: <B4uwt1P0z6WkkigiVJQWlPp2nOB4vKzLhrWvkv3-hfw=.4d476b03-9d97-4c83-bceb-848345b874b4@github.com>

On Tue, 6 Jan 2026 23:41:52 GMT, David Holmes <dholmes at openjdk.org> 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: <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
 <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@github.com>
Message-ID: <ZyuCgDuiltet96TpTCBTSI3W7UJN8dNBrGXigVyKDLI=.a5083564-d1d8-4fc9-baf5-762f7ce567d0@github.com>

On Fri, 9 Jan 2026 17:43:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
Message-ID: <gpJ1pNf5PvD5gQYM7BxjmpyyZyVKAwdAUpSRznRtH4I=.015128e1-189a-4ac2-a8ca-e13999b77304@github.com>

On Fri, 9 Jan 2026 17:26:04 GMT, Larry Cable <duke at openjdk.org> 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: <ZyuCgDuiltet96TpTCBTSI3W7UJN8dNBrGXigVyKDLI=.a5083564-d1d8-4fc9-baf5-762f7ce567d0@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
 <kIaJ-2TNRMtaTAwa1vQhr1qzT_wMZWJO9xexzC-mP6k=.a33595e4-026b-4529-8f0f-f6a47cc1efff@github.com>
 <ZyuCgDuiltet96TpTCBTSI3W7UJN8dNBrGXigVyKDLI=.a5083564-d1d8-4fc9-baf5-762f7ce567d0@github.com>
Message-ID: <-dk0O-wXKH9LTKENWaUTda4MJFuZo2bCeM7q4FpBSgQ=.ce715b56-569f-4693-8230-772753b408d1@github.com>

On Tue, 13 Jan 2026 05:26:44 GMT, David Holmes <dholmes at openjdk.org> 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: <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
 <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>
 <Y6_Tl23eRMm5JM-veOrfdr6Ajn2ZjI3VKZBsQ_cSEEg=.4c38315c-404c-446d-9265-de88c40b9d67@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 <duke at openjdk.org> 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: <XtPOl54uhDe9o3Q6cNO9w-ffhuMC6LsbNVs222BhAdA=.83ae5455-b8cb-403e-86fd-d149ec86dcd8@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <XtPOl54uhDe9o3Q6cNO9w-ffhuMC6LsbNVs222BhAdA=.83ae5455-b8cb-403e-86fd-d149ec86dcd8@github.com>
Message-ID: <PeYHiky4dcO7JKsmsQNW6e3uTRmf7e5ygjaIf2t0s6Q=.2fd265e6-68bd-474f-a2af-b6a7581c540f@github.com>

On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable <duke at openjdk.org> 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: <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
 <iWeo9VV0swA4s8IkhB9DhR6h6eF-81-i2SXkPp7NTWo=.3ac14c14-3dd4-4f71-a9ff-35823b9aa015@github.com>
Message-ID: <EUmxnOe8FZKkplRRxRKFxa6Bt5YZrbGIKC7-5NkXw3A=.e78b4654-6b65-45e9-9a93-f9408da26bcb@github.com>

On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Delay suspender whilst target is in-critical
>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>    
>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.

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: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
References: <yJ31YGeSwcwmMyrCSBInDrj3EDA2VRkGz9FPQ5r5f4g=.2fae5898-da43-4b7f-a35e-944abbc46c9d@github.com>
Message-ID: <TUNT6k21tFiWHyEiFBLGhtxIUhCfirOYLrs9q24-TEI=.c718237f-4586-4a77-b833-5ea67223e547@github.com>

On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
> 
> The mechanism for this already exists courtesy of the virtual thread support.
> 
> Testing:
>  - tiers 1 - 6 sanity

This 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: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <WEIkBbqpEIS5BtGtX9yamHRNnDJXtCIs1i9qx1zaj4M=.b1238367-6da8-4a4b-8091-773222661018@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
 <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 <psandoz at openjdk.org> 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: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <QD9dKun3woEYzBrqLtNCUTHb_NdsUvF1kJQ1-m5ZjEE=.aa32c2d9-8812-4f59-bde8-47c331a7ba1a@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  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: <BTvNZTd5A6PrXD1gARtQ0r3wtAkpzcjbunbkBFPwIQs=.c277bf29-1c32-45ef-98a1-536db7f52808@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
 <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
 <BTvNZTd5A6PrXD1gARtQ0r3wtAkpzcjbunbkBFPwIQs=.c277bf29-1c32-45ef-98a1-536db7f52808@github.com>
Message-ID: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com>

On Wed, 7 Jan 2026 09:03:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893:
>> 
>>> 1891:         VectorMask<Float16> 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: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
 <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
 <BTvNZTd5A6PrXD1gARtQ0r3wtAkpzcjbunbkBFPwIQs=.c277bf29-1c32-45ef-98a1-536db7f52808@github.com>
 <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com>
Message-ID: <J7k-JSqw0lEoKFQcDvf8dJpS5zsKAOpO-LqGvhnEmVI=.1a4a0cfd-b133-4c2e-b8da-af021db82932@github.com>

On Tue, 13 Jan 2026 10:10:40 GMT, Fei Yang <fyang at openjdk.org> 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: <QD9dKun3woEYzBrqLtNCUTHb_NdsUvF1kJQ1-m5ZjEE=.aa32c2d9-8812-4f59-bde8-47c331a7ba1a@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <QD9dKun3woEYzBrqLtNCUTHb_NdsUvF1kJQ1-m5ZjEE=.aa32c2d9-8812-4f59-bde8-47c331a7ba1a@github.com>
Message-ID: <GZMGhUmBcMk4C8ntrdcSkQe8qbw_VYoLC7844Ifc0fQ=.9bc8e70d-67bc-440b-808c-19b3134eb8ab@github.com>

On Tue, 13 Jan 2026 09:58:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request 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: <bQAuJ9_fCGmjsh4_MyVIsOQKeddqY6Fmlu5TT-JvKVmWYbYeo5F4WySZdGc76z64zFQADhx-GJEHkaHW7cQ8CgyAILtDKgQkjIBxJdooRhc=@pm.me>

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: <bQAuJ9_fCGmjsh4_MyVIsOQKeddqY6Fmlu5TT-JvKVmWYbYeo5F4WySZdGc76z64zFQADhx-GJEHkaHW7cQ8CgyAILtDKgQkjIBxJdooRhc=@pm.me>
References: <bQAuJ9_fCGmjsh4_MyVIsOQKeddqY6Fmlu5TT-JvKVmWYbYeo5F4WySZdGc76z64zFQADhx-GJEHkaHW7cQ8CgyAILtDKgQkjIBxJdooRhc=@pm.me>
Message-ID: <f86e9198-2e3a-45af-b726-84360a4ee971@oracle.com>



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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260113/ac2540a6/attachment-0001.htm>

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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@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)

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: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>

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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
Message-ID: <360N0pFKAVnWO5eHeAi3XCvBEIesJCTAIWcooPYP_uw=.faa035f6-0380-4707-b21b-86ed97fe6d80@github.com>

On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable <duke at openjdk.org> 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: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
References: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
Message-ID: <0pbt6G2mVWTJYMDYqoIEHjevbI4zKvA08P-Bm_820Rk=.c811cf19-be11-4627-a967-cad58610c9c1@github.com>

On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
References: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
Message-ID: <H9ut7dQtTxQeNyHT9X_q8kD2lPTSYfvN-QDT6XA37DM=.4f88424c-9a91-44f2-a9b9-33cf042f02ea@github.com>

On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
References: <xYiQXkbKS7hwr3MtYsZc8sNcgjtqI_n4K_talhXHw9g=.f0fc1aa7-e58f-49f6-bd52-9b8d80d89239@github.com>
Message-ID: <M5ZrAFQOP7ADzA6YcKHg6nN9b08jfRqzD1o2nm4HJTM=.87332365-25a3-49cb-b683-88fbe7f39cb4@github.com>

On Tue, 13 Jan 2026 23:36:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com>
Message-ID: <uGI3sJpPV3HojaLMX65GwJP4Xt4eY1kG3N18jJw5Llw=.0e586e27-1dfa-4127-8939-03fbce078386@github.com>

On Sat, 10 Jan 2026 08:15:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: 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: <q03ycurNrC_Oyn-fGH4hn8Zt_FHry8KByk2qhisZ8c4=.76547ec9-0138-40e7-a6db-ea4d58cd350a@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
 <q03ycurNrC_Oyn-fGH4hn8Zt_FHry8KByk2qhisZ8c4=.76547ec9-0138-40e7-a6db-ea4d58cd350a@github.com>
Message-ID: <faiyH_x6RrsAsWmBEUCOXhNFQthSBc9E8YmQgxCCsLk=.71c0b68c-56f3-4b81-88d0-df55f74a84b1@github.com>

On Wed, 7 Jan 2026 06:09:19 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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
>> 
>> 
>> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
>> 
>> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
>> 
>> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
>> 
>> 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: <Uc6-L2ELP00ItOYnweeR8xWiEK48tiHnf-yMZbustiU=.00a1ca86-0413-4a15-9fdf-2451207d1e3f@github.com>
References: <JLHtSmwk1DFaIckVSyMZWhLaGkDd4P1wwhH02Z9Iykc=.5046561f-3812-4e90-b25a-6ebf5b6704bb@github.com>
 <Uc6-L2ELP00ItOYnweeR8xWiEK48tiHnf-yMZbustiU=.00a1ca86-0413-4a15-9fdf-2451207d1e3f@github.com>
Message-ID: <LiGfSbxv9-e3lhl7YcvOJQ77zIhCZ5HHbSVZbRtr5nk=.19d56cac-f9ea-4d3d-b7ac-55106b5cf15c@github.com>

On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with 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: <YkZYGAJz2NV7CeRdS7_MS4vCx3fCWTx8gU1aqWmjlZ0=.333579bc-1a35-4a31-aec0-7065b2a1e3de@github.com>
References: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com>
 <58NEO2nfcPHreBIpKjcmfp8iBCGbO0MpCtgLt4ZAYFY=.c28a57f7-44f2-400c-ac26-0b97f6a5a806@github.com>
 <YkZYGAJz2NV7CeRdS7_MS4vCx3fCWTx8gU1aqWmjlZ0=.333579bc-1a35-4a31-aec0-7065b2a1e3de@github.com>
Message-ID: <X00nmhfHjapv_b0K5H8M2HhjgQmelSzz5Dc60OWmbmI=.08688269-6312-41e7-abbf-dd55772d2f0f@github.com>

On Mon, 12 Jan 2026 12:06:04 GMT, Kevin Walls <kevinw at openjdk.org> 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: <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
Message-ID: <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>

On Sat, 10 Jan 2026 01:57:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <xEDkdIhzs0VPul1iQsDmuUiOl5cb5Nsl1qp8QOUIg_U=.7d2ab037-91af-4263-9e1c-eb8edd795814@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <xEDkdIhzs0VPul1iQsDmuUiOl5cb5Nsl1qp8QOUIg_U=.7d2ab037-91af-4263-9e1c-eb8edd795814@github.com>
Message-ID: <xAjV--9DciImgA41pOR0xbLtk04Sm_ns1wWj7joLGKE=.2792f39a-8558-47fc-9028-a42ed3be58b7@github.com>

On Sat, 10 Jan 2026 03:23:52 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
>> 
>> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
>> 
>> Additional testing:
>> 
>> - [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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
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: <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
Message-ID: <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>

On Wed, 14 Jan 2026 05:31:24 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
 <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>
Message-ID: <7kgAC4XAKsAf5OWtcoKHzLWZ9-X-7gkrSqZWlGfaswo=.60598d6d-f3a0-440d-a953-bf82de55a268@github.com>

On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan <syan at openjdk.org> wrote:

>>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments.
>>> 
>>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader.
>> 
>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews.
>
>> 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: <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
 <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>
Message-ID: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com>

On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan <syan at openjdk.org> wrote:

>>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments.
>>> 
>>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader.
>> 
>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews.
>
>> 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: <GZMGhUmBcMk4C8ntrdcSkQe8qbw_VYoLC7844Ifc0fQ=.9bc8e70d-67bc-440b-808c-19b3134eb8ab@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <QD9dKun3woEYzBrqLtNCUTHb_NdsUvF1kJQ1-m5ZjEE=.aa32c2d9-8812-4f59-bde8-47c331a7ba1a@github.com>
 <GZMGhUmBcMk4C8ntrdcSkQe8qbw_VYoLC7844Ifc0fQ=.9bc8e70d-67bc-440b-808c-19b3134eb8ab@github.com>
Message-ID: <ch5EONK4deJvbZg1KHw6dMJP6i2lKtUBLB9WBIcw4yg=.b5ab1b5e-de99-4819-baea-4bb84306fd52@github.com>

On Tue, 13 Jan 2026 10:22:25 GMT, Fei Yang <fyang at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <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 <duke at openjdk.org> 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: <ch5EONK4deJvbZg1KHw6dMJP6i2lKtUBLB9WBIcw4yg=.b5ab1b5e-de99-4819-baea-4bb84306fd52@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <QD9dKun3woEYzBrqLtNCUTHb_NdsUvF1kJQ1-m5ZjEE=.aa32c2d9-8812-4f59-bde8-47c331a7ba1a@github.com>
 <GZMGhUmBcMk4C8ntrdcSkQe8qbw_VYoLC7844Ifc0fQ=.9bc8e70d-67bc-440b-808c-19b3134eb8ab@github.com>
 <ch5EONK4deJvbZg1KHw6dMJP6i2lKtUBLB9WBIcw4yg=.b5ab1b5e-de99-4819-baea-4bb84306fd52@github.com>
Message-ID: <53ngdNhoWJy4Cacq2Xs1bC0ulSPPVcUdz6WoSb3Pp6U=.699dfca7-3a7c-4f6b-addb-3c26b8f4c357@github.com>

On Wed, 14 Jan 2026 10:58:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
Message-ID: <1UIQCA4KZxbcVPvePdiXUYmBBdxOhmnK779XX85qIPo=.ea87b867-ee1d-4385-935b-a656591d9f5e@github.com>

On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable <duke at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com>
Message-ID: <udqQcMSS1iZjs-vADproU-vaRpg69JuekqRLmXyKJK4=.c196eade-9de1-4ae8-bcae-bc9ca8783ff2@github.com>

On Fri, 9 Jan 2026 18:38:53 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
Message-ID: <j6cijzf1ntm2psE4YX2YX9v-0Nvo8kin56Km-0nimM8=.d3b4b998-82ef-47d6-878e-f7ff42ba83af@github.com>

On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan <syan at openjdk.org> 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: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@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:

  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>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
 <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>
 <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com>
Message-ID: <SvXiTC8dyH38Gw5WTj-SItG8PEwvbKiBUlpCYDY3oNY=.c1aa291f-e2a0-45b6-be0f-3498dd0b90f9@github.com>

On Wed, 14 Jan 2026 07:55:31 GMT, SendaoYan <syan at openjdk.org> wrote:

>>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews.
>> 
>> All the comments in touched tests has been checked.
>
>> @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: <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
Message-ID: <2qqTzoiovGkzLDS9fLbDABmH9-2I0TJlOKkJtpmB6GQ=.0fb59191-e674-44f0-bbc7-686cb0a0f61f@github.com>

On Sat, 10 Jan 2026 03:02:24 GMT, SendaoYan <syan at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com>
Message-ID: <FF4Tj4I2CZwRw4d1PH7p8JfYHEDitYlIGm5M04mRta0=.e6162369-cc62-424f-8ad2-5f688a5bbf37@github.com>

On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son <duke at openjdk.org> 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: <uGI3sJpPV3HojaLMX65GwJP4Xt4eY1kG3N18jJw5Llw=.0e586e27-1dfa-4127-8939-03fbce078386@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com>
 <uGI3sJpPV3HojaLMX65GwJP4Xt4eY1kG3N18jJw5Llw=.0e586e27-1dfa-4127-8939-03fbce078386@github.com>
Message-ID: <IqDCvKJMwDAEc-j-2WKzPGSk55RpM9BLVbFngSWLEys=.68ab3741-eb7a-43a1-8a4e-ea957713bab1@github.com>

On Wed, 14 Jan 2026 01:27:45 GMT, David Holmes <dholmes at openjdk.org> 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: <WLfyJ1KdNnwCM3hIi4OnYkibVGF5nywahqibsPg3SCA=.f39d7a02-0527-4b30-932a-e21e32dd1707@github.com>
 <8fsOgrLGpZgxG_IOCR0ExtHG1LRZDg6ImXi7Y-C2SUM=.aa9a1188-2df4-4710-9903-96b0fff35f3b@github.com>
Message-ID: <HUVDLwYGoep6otp9xHJoGs3osecIRUPPpUVhaiAKhv8=.3d2c6224-31ea-46cc-96ae-898e9cf25fb3@github.com>

On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son <duke at openjdk.org> 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <ndnV9FHAFPAnY1gEC75pRVUHbq5cBweBMlsjRGXVKJk=.8f5df5b5-1b06-4398-ae06-e979de8f6974@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 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: <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
Message-ID: <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>

On Wed, 14 Jan 2026 06:02:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <EEFslrg2tkf7WDd7dw1TCYPU42grn-8Of-FP_cS0oe4=.3b14a2b4-d524-49f4-9d61-f195eb959cda@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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 `<signal handler called>`).  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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <vvOD1Kk6Q3vScrcvCDv_amtybhZW4dTRD45z94-gW90=.c1e94345-9845-4532-bf0b-6efb002e1a7f@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
Message-ID: <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>

On Wed, 14 Jan 2026 22:46:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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:

  <snip>

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)

  <snip>


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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <N3LE1nsnFD6zbREJ8A8Z4LQPjFQGmR8gjIIaYOd1xSA=.ae112856-2de1-4471-8ace-95238ef999f5@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: 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: <N3LE1nsnFD6zbREJ8A8Z4LQPjFQGmR8gjIIaYOd1xSA=.ae112856-2de1-4471-8ace-95238ef999f5@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <N3LE1nsnFD6zbREJ8A8Z4LQPjFQGmR8gjIIaYOd1xSA=.ae112856-2de1-4471-8ace-95238ef999f5@github.com>
Message-ID: <IwwaLTDc_V3QjMlyaTJ7h_XbZkH5s-UJkN5tAgJfGsQ=.230a4fbb-1391-4b90-8ffd-be8e513743b3@github.com>

On Thu, 15 Jan 2026 01:23:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: 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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <lHeKE9_SD-7e-y1P1eT3DcqSBCuZLFBX5_bxR9utGpI=.13cb906e-8b24-4c0b-9947-3c42740369a1@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
 <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
Message-ID: <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>

On Thu, 15 Jan 2026 00:49:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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:
> 
>   <snip>
> 
> 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)
> 
>   <snip>
> 
> 
> 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	<StubRoutines (initial stubs)>
0x0000023f93009300	* LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame)
                  	* LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame)
0x0000023f93001952	<StubRoutines (initial stubs)>
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	<StubRoutines (initial stubs)>
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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
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: <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
 <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
 <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>
Message-ID: <A3c1zimnV7a63LfM3faMibgwy5abjkEaDMfNAXLlZ_I=.37c7bcd7-91ba-4f5a-acb9-0bd9f3c60512@github.com>

On Thu, 15 Jan 2026 01:29:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> On my Windows 11 25H2, mixed jstack works correctly like following:
>> 
>>   <snip>
>> 
>> 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)
>> 
>>   <snip>
>> 
>> 
>> 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: <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
 <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
Message-ID: <YpIn84s-DejwUAI19GKLE1c4OXJbOLOqRjYydWVEpeE=.d4bd5a39-4dfd-46e2-89ab-c543114fb92e@github.com>

On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
 <MrAyVDpY7-BMuVwYq-aT6Zql-eEwvG9o7y9mvHcXXeY=.384e20cc-cbcb-423c-a971-b060cc2bfa9a@github.com>
 <2qqTzoiovGkzLDS9fLbDABmH9-2I0TJlOKkJtpmB6GQ=.0fb59191-e674-44f0-bbc7-686cb0a0f61f@github.com>
Message-ID: <bHR_hFcNLZ9m1WNBuxLHIHN-pdAJrcQpPEWAvAb-hN4=.8040067f-0f73-4ea4-9b97-f9ffcdb37bb3@github.com>

On Wed, 14 Jan 2026 16:09:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
References: <q8JW7BeLfxdNWSWrBLEtl5WqcB7uviH5e_E9Bx2Tfnc=.ede17e20-e606-4c23-b2f4-8c0fd2544bc9@github.com>
Message-ID: <4WLwRmH9gGIJvLuvdWaD0GvnBc3M6BMroGIylzhPWUo=.7fd1507d-91ee-4db8-a39a-8c6ac7b3215f@github.com>

On Fri, 9 Jan 2026 13:41:22 GMT, SendaoYan <syan at openjdk.org> 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 <syan at openjdk.org>
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: <pfGsTVYawL6Hp-apPu5Kd22R_OW3PtYqu0MWQhWfN-A=.f0592d36-1f59-4aa9-ba5d-f684b49c3992@github.com>

On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time.
> 
> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64.
> 
> Additional testing:
> 
> - [x] All jtreg tests by fastdebug build

This pull request has now been integrated.

Changeset: ce5e0d8a
Author:    SendaoYan <syan at openjdk.org>
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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <SdcTggdpgcvTqzdlfHmP9snlW167h1wpvxSMFqf80ls=.a72387df-71a7-4dda-84f4-c1f00cb450d8@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <A3c1zimnV7a63LfM3faMibgwy5abjkEaDMfNAXLlZ_I=.37c7bcd7-91ba-4f5a-acb9-0bd9f3c60512@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
 <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
 <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>
 <A3c1zimnV7a63LfM3faMibgwy5abjkEaDMfNAXLlZ_I=.37c7bcd7-91ba-4f5a-acb9-0bd9f3c60512@github.com>
Message-ID: <VQTitz65JvSELcguYvz32yuka1Ka9ypbqIhAiM_NaWM=.80616b52-faaf-4ac7-b43a-e10f16f410c5@github.com>

On Thu, 15 Jan 2026 02:23:54 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
Message-ID: <Mg0OJ3ShgzAz6n6Yk28Nj0eYD_HboI0jPEKJXr3iW_k=.1403a234-42ce-45a1-9492-db153f61ffe7@github.com>

On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable <duke at openjdk.org> 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com>
Message-ID: <ZCxxhY8Qw09U1HqU-se1dshGst9w7sTfPWG7kx6Bi7w=.66189c68-c878-4ce1-95b0-550bd3dada1e@github.com>

On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com>
Message-ID: <o0_KZrj76yPSSVTFXTrJwet070SMmmc1L2067zTzNV4=.a8690c4e-b4c2-491a-8afd-07ce4c731e1c@github.com>

On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread.
>> 
>> This is fixed by a small tweak in the function
>> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`.
>> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`.
>> 
>> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product.
>> 
>> Testing:
>>  - In progress: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   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: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>

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: <VQTitz65JvSELcguYvz32yuka1Ka9ypbqIhAiM_NaWM=.80616b52-faaf-4ac7-b43a-e10f16f410c5@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
 <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
 <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>
 <A3c1zimnV7a63LfM3faMibgwy5abjkEaDMfNAXLlZ_I=.37c7bcd7-91ba-4f5a-acb9-0bd9f3c60512@github.com>
 <VQTitz65JvSELcguYvz32yuka1Ka9ypbqIh
 AiM_NaWM=.80616b52-faaf-4ac7-b43a-e10f16f410c5@github.com>
Message-ID: <Lh5FJ6kSls_w4-_QeIhyVg1iKodQjCLvwM0NbSmpGw4=.a4418a1f-4ebb-454f-ba6a-42a35e2f96c8@github.com>

On Thu, 15 Jan 2026 04:52:19 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <RXFkE-AX1Vqj22dpWjKhPSGjs_NyOZKPxKGzxcJDQws=.3c96cdfb-7d3d-407c-b820-fce1547cab10@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
Message-ID: <GLLvnx9Wq1DieraD2FcFKWLFPAVjzJNvuFp3DlPSkPE=.abb76e43-5425-4982-9890-1686f622a0db@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: 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: <o0_KZrj76yPSSVTFXTrJwet070SMmmc1L2067zTzNV4=.a8690c4e-b4c2-491a-8afd-07ce4c731e1c@github.com>
References: <oyJAiPdK9TtdSujtLCkNiT2YFPPCFbsLEZI4cdAn2-A=.b3191770-a260-4c67-80c1-6bfb64c2d3d2@github.com>
 <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com>
 <o0_KZrj76yPSSVTFXTrJwet070SMmmc1L2067zTzNV4=.a8690c4e-b4c2-491a-8afd-07ce4c731e1c@github.com>
Message-ID: <d8ELsUxT9Bec7q5SYmeRGTQPnNUoy62Auxu44NjLuso=.a1616800-0843-4eed-8f04-ec45efc2c7d2@github.com>

On Thu, 15 Jan 2026 06:01:39 GMT, David Holmes <dholmes at openjdk.org> 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: <f86e9198-2e3a-45af-b726-84360a4ee971@oracle.com>
References: <bQAuJ9_fCGmjsh4_MyVIsOQKeddqY6Fmlu5TT-JvKVmWYbYeo5F4WySZdGc76z64zFQADhx-GJEHkaHW7cQ8CgyAILtDKgQkjIBxJdooRhc=@pm.me>
 <f86e9198-2e3a-45af-b726-84360a4ee971@oracle.com>
Message-ID: <Ik0Zp-PbSB3iwfHqWUhnjXzHV6V71-jIDU3FjzLFPNNNiR9GYGLo0e3QGxjrE_2Lsr4oX-5X5nP1_qBPmNE2Rei3_q1VjjwAmnDH0j186AI=@pm.me>

>> 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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260115/b4d914a9/attachment.htm>

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: <Ik0Zp-PbSB3iwfHqWUhnjXzHV6V71-jIDU3FjzLFPNNNiR9GYGLo0e3QGxjrE_2Lsr4oX-5X5nP1_qBPmNE2Rei3_q1VjjwAmnDH0j186AI=@pm.me>
References: <bQAuJ9_fCGmjsh4_MyVIsOQKeddqY6Fmlu5TT-JvKVmWYbYeo5F4WySZdGc76z64zFQADhx-GJEHkaHW7cQ8CgyAILtDKgQkjIBxJdooRhc=@pm.me>
 <f86e9198-2e3a-45af-b726-84360a4ee971@oracle.com>
 <Ik0Zp-PbSB3iwfHqWUhnjXzHV6V71-jIDU3FjzLFPNNNiR9GYGLo0e3QGxjrE_2Lsr4oX-5X5nP1_qBPmNE2Rei3_q1VjjwAmnDH0j186AI=@pm.me>
Message-ID: <eda2b1f7-876b-449b-80f8-1ef549efd38a@oracle.com>



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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20260115/2174f505/attachment.htm>

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: <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
 <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
Message-ID: <mrZHY9MPMwMX-RI0ksrKg1HYs9VZVZvek04nzCZLGHY=.bbb4efc0-2415-4581-93e7-62c4e2b8bf45@github.com>

On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
>> 
>> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly.
>> 
>> Thanks!
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an whitespace after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
References: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
Message-ID: <IPsZDbFeC7h3ChkYKqDsaBWUecELL0YoXTZlQrydWqQ=.000cae28-6fe0-4aa4-8242-c5e238f7da9e@github.com>

On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan <syan at openjdk.org> 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: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
Message-ID: <D8iOsv3z_aVsOSG4w7Yh3o6ZRYHLv0zu_K-Ndg50-wU=.7d4e7e8c-d120-4cd8-b7ca-9dab64f1f24d@github.com>

On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
Message-ID: <OOnTWuGKrSHdjao09mm7Yfg2bpfUIW81RKTRxe_g57c=.2e602c35-72a3-4966-9ac0-4dddf9130a3a@github.com>

On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable <duke at openjdk.org> 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: <Oo6xeE8jAJ7yxl5lBp5_mdI-6_NI3e0TJlRe5ffXtg0=.73aeee65-6899-4bbf-8b0b-a7b92eb2b53a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>
 <Oo6xeE8jAJ7yxl5lBp5_mdI-6_NI3e0TJlRe5ffXtg0=.73aeee65-6899-4bbf-8b0b-a7b92eb2b53a@github.com>
Message-ID: <LnuH93qWIliJSMflZK-kMCrj5aVoudew8yBB7ejSiq0=.07bbe07b-c5c4-4354-b3ae-454a98a9c7ab@github.com>

On Tue, 6 Jan 2026 21:31:06 GMT, Larry Cable <duke at openjdk.org> 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: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <942hFMToF2FlZIhxEuvzXdKX6JwV_KMWTUbXxmF6eDs=.46367649-0d0c-47ea-b91f-3fd10e71cd2a@github.com>
Message-ID: <mFrMvBC9dDxeQxaT6YvL85yRUd3NviMQipRVwbP_4MU=.8c14c6d6-a2b2-4d60-92fb-97d77cf0b515@github.com>

On Wed, 14 Jan 2026 06:06:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <Lh5FJ6kSls_w4-_QeIhyVg1iKodQjCLvwM0NbSmpGw4=.a4418a1f-4ebb-454f-ba6a-42a35e2f96c8@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <QoAOar1vFy4iMyxwqXgb-R-ty-ZOpPeJJUQc_49OklY=.5a0c19d3-9b18-46ba-8b52-5ae1ab5be393@github.com>
 <r9729XNGLxHHYPJV2jt515lTQPXepEKuYuJO57MrhUo=.876276eb-ff09-48b5-a727-adb2ab79f3d2@github.com>
 <ulMHaeF5uZlmdjWQrVoCwdrWvNWOpoOIvYVgCE33o4g=.39e06bdb-da43-431b-bd88-8ce43914e817@github.com>
 <TAZjQGhrD0nsKQZxVAh1MGS7DIR6IkI_bN5BZOmtvdI=.97a75bb4-c21c-4bd4-9158-f9be85057b7f@github.com>
 <AeCpTmJMHQRZwi2Jin37b-OvXc0dDUrnbRFXEBoCQ9Y=.39dd0496-c1c5-4e76-bc6d-e33c62038d1f@github.com>
 <E6FJ82pldvhcm5QjtNGDyJNzhizR_5Qm9_OaZm-x4yU=.bf0a98f4-f778-4151-bb8f-32aef11fd2dd@github.com>
 <owlTl3Gz5DUEM8ejQqCf-08MvkDtT6XzTzU0GSQBpaA=.9b135276-80c0-4e86-8f32-608a492f1b71@github.com>
 <vEXj1BYmOwtVPi2EM0rao_0eNbq2M4NazYo8HEWqcSU=.e4ad6741-7281-4b32-ae7e-80997dc4714b@github.com>
 <A3c1zimnV7a63LfM3faMibgwy5abjkEaDMfNAXLlZ_I=.37c7bcd7-91ba-4f5a-acb9-0bd9f3c60512@github.com>
 <VQTitz65JvSELcguYvz32yuka1Ka9ypbqIh
 AiM_NaWM=.80616b52-faaf-4ac7-b43a-e10f16f410c5@github.com>
 <Lh5FJ6kSls_w4-_QeIhyVg1iKodQjCLvwM0NbSmpGw4=.a4418a1f-4ebb-454f-ba6a-42a35e2f96c8@github.com>
Message-ID: <fO_Uzt3N-3Ny5pxFIZF5esOMsVUwRbryKhQJ_2sSg74=.c83b87d4-170f-4f39-acc1-23556c5e2132@github.com>

On Thu, 15 Jan 2026 08:13:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
References: <SmrtG1zXKw4hPV7XJC_A7vB_R9NCZW2znpQwD-B0dq0=.266e19c5-fb45-4b7c-a0a8-267cf64c1190@github.com>
 <aMx_XmLhnedGaJUYHRUyaVgMvwpIIh0L6q4DCPvDFdI=.03625f38-142f-4cdb-867e-b9f5eefd0d94@github.com>
Message-ID: <y2bzfCYKgjgH0rIXfZaGfjPsopBxkqOzIMvY1nRJ3PY=.ede17e60-79fe-43de-a9a3-535d1ae82fee@github.com>

On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <StubRoutines>
>> 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 <signal handler called>
>> 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: <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <PbDfMBtZRHFIGRygI9LpT4-Qf0OyTssSnIWKMAWycMg=.be570580-d9ed-40c0-a3f3-63f7fe1068cb@github.com>
Message-ID: <5THP-X2kZyt8lDj1tEPloBnzo3pG5hpHbzJewqcVNzQ=.3b8b92c8-dcd5-48a3-911c-ddf9d97f44f9@github.com>

On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable <duke at openjdk.org> 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: <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@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)

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: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
References: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
Message-ID: <wHatZzWGp8x3QpmKvgqtXX9vp758P8YrhN8RER7LAh4=.e0ce6bd4-e68f-4035-8c14-79af3a02ccdb@github.com>

On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan <syan at openjdk.org> 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: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
References: <FqBiQfpMNNhLYqWtzwuSVgHA3MJT-FwRvjf3fyHsPyk=.4a189c36-5666-4d5a-b9ad-180e7e8ffec1@github.com>
Message-ID: <AQZXR2wAF_Lno3CvLuLgH0WEvvkDsWtqiK8CgTclOYQ=.01777227-ba77-4ce4-87d5-2c360b508bd2@github.com>

On Thu, 15 Jan 2026 06:59:26 GMT, SendaoYan <syan at openjdk.org> 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: <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
Message-ID: <VuKxgSdmLCg6Tj9KHc0PuT8RHRPn5QLs1QQiEuPTN4U=.9dfa3f91-ee07-41d0-a5ae-3fda4f7bd7d3@github.com>

On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable <duke at openjdk.org> 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: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
Message-ID: <dpc56DVRmXq1MK9XseCzSoQLOqCYtP4Tiz9quTsy7r4=.40e8ad2f-c19a-435f-859d-c223bbb38365@github.com>

On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
Message-ID: <BbzGSD_ZcsQ_G4MF8MGQc5r9v0_FZpHj-xv7Mn0aHBo=.f22626c6-1df9-4c8a-8d8b-ed7eedbe99e8@github.com>

On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable <duke at openjdk.org> 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: <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <EMXqDjhjxT9nlD8MKVWjeoe7tMfS0SnViqfLqw_XkL8=.63cb1f5f-7225-4a03-9824-f995f7f17f2a@github.com>
Message-ID: <FgEx5IBsFO2hdr9rvwNK32nhjI_EiQ_HkBa6g3VgVug=.ef60c9e7-48a9-4636-93fd-32c27d9f111d@github.com>

On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable <duke at openjdk.org> 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: <vxDO9ehyy7d6JGCjp9TY8705rYxnnqfoEH6A2FTKd8o=.ca8b8752-f3eb-4c3e-be8d-720d84f39e00@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)

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